Search code examples
javamavenprojects-and-solutions

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.

Solution

  • Ill try to answer the "share sub-products" part of your question.

    • Set up your own internal Maven repository (assuming you don't have one yet). We use Nexus which seems to be adequate.
    • Move the common code out of the application hierarchy to a top-level project with an appropriate name (e.g. ProductPojos). Give this a suitable group name space (e.g. com.mycompany.product.common)
    • The output of this project should be a jar file, which you can release to your Maven repository (A CI tool like Jenkins will make this easy)
    • Each application project that needs the Pojos now simply needs a Maven dependency declaration, usually with compile scope, so that the Pojo jar will be included in the application output artefact.

    This style of project structure has the advantage of enforcing a clean separation of concerns. We regularly include internal library code in multiple projects.

    Good luck.