dimanche 29 mars 2015

managing local namce project name clashes with and between Maven projects



I've found Maven to be a very useful paradigm for project work probably largely because of the repository concept. I have uncovered a speed-hump at the moment, for the most part from my point of view, at the same time there's a valid observation here and I expect you or a colleague will have some solution(s) for this dilemma.


My perception is that Maven is a project level tool and lets you assemble your project from other projects as building blocks (Maven artefacts). I am going to give a dumb-down example of what I'd like to achieve using Maven on projects. I'm referencing



For the purpose of illustrating the example consider everything is in the same group umbrella:



  • com.product


For a moderate size app, I might have a couple of sub-projects/modules, consider the following example. For development I'd like to organised project as various sub-projects.



app_one
|
+-- pom.xml
|
+-- gui
| |
| +-- pom.xml ....... <artefact>gui</artefact>
|
+-- datastore (DAL) ... <artefact>data</artefact>
| |
| +-- pom.xml
|
+-- domainentities .... <artefact>entities</artefact>
| |
: +-- pom.xml
:


I am looking for a good way to separate subsequent (structurally similar) application, e.g. app_two. How do others organise the project to avoid artefact names clashes. The <groupId> and '' are the only things that distinguish a sub-module. The <version> number should be specific to that, 'groupId:artefact` pair



app_two
|
+-- pom.xml
|
+-- gui
| |
| +-- pom.xml ....... <artefact>gui</artefact>
|
+-- datastore (DAL) ... <artefact>data</artefact>
| |
| +-- pom.xml
|
+-- domainentities .... <artefact>entities</artefact>
| |
: +-- pom.xml
:


Between the two example apps, app_one and app_two there are now two:



  • com.product:gui

  • com.product:data

  • com.product:entities


artefacts which are conceptually completely different and distinct. The builds are local projects and the sub-projects are internal use.


The thing is avoid artificially long names and avoid the need to invent names for commonly used project nodes (e.g. GUI) and secondly when things are named according to a common scheme it lets us have scripts and tools to carry-out some common tasks.


Is this something with a standard pattern? I don't want to reinvent wheels that work quite well already.


A second thing; something like:



  • data


Can often be re-used across different app projects. So the second part of the deal might be how do people share sub-components across projects with Maven? The attempts we used to date didn't workout very well.


At this point it looks as if Maven is great for building the application building blocks, say a log4j or jdbc-driver. What's good practice on the application sub-module level?


possibly related questions :


I feel these questions are covering similar ground as well just to provide depth for the question at hand. There's no answer as yet.



For the moment, I'll add that we want a Maven solution - Gradle or alternatives are out-of-scope just now.




Aucun commentaire:

Enregistrer un commentaire