Maven naming conventions for hierarchical multiple module projects

Question

I\'ve got a question on Maven naming conventions (groupId, artifactId and directory names) in a multiple module project with a hierarchical directory structrure.

Resear

Answer 1

I don't think there are conventions that would clearly specify on how you should setup your project structure in this case.

E.g. I would try to answer where the artifacts end up with their name and whats the chance of running into a conflict. For a framework like spring it does make sense to have the project name in the artifactId ("spring-*"), same is true for commons- libraries (although "commons-logging" may by a risky name).

For a project that runs standalone I is probably not necessary to do this. But it looks like you will use a liferay portal where a lot of different jars will be around so I would encourage a prefix for the artifacts. But I would not try to rebuild the project structure based on artifactId's. So "project-modulename" will be a good module name. Since the jars will build the classpath and the dependency structure was defined during the build this is not an issue. If you need to rebuild the dependency tree based on a list of jars: maven includes information in META-INF (if you use the release-plugin, which I also recommend) so the information can be retrieved from there.

I would also recommend to not nest modules to deeply. Eclipse has some issues with this (IntelliJ does not, Netbeans afaik supports nested structures too).

The main portal module may not change that often compared to the plugin modules. So I makes sense to split them into separate projects - this would also allow to release the projects separatly.

For me it is a good practice to name parent modules with "-parent" suffix. These modules are rarely used as dependency and a "-parent" for a dependency would indicate something is suspicious. As you said: artifacId and module name should be the same. I would also recommend using the artifactId as name in the pom. Some plugins dont consider differences here and also Eclipse behaves better if these values are all the same.

It is true the goupId and the artifactId often contain duplicate information (e.g. parts of it will be the projectname). If this was done on purpose or happend in the last years...? I dont know but I would keep it this way. Artifacts are identified using the GAV(P) coordinates (groupId, artifactId, version, (packaging)). If groupId or artifactId contain the projectname artifacts are more easy to find if you only have one of them.

Finding artifacts is easy if you are running a repository manager (like Nexus, Artifactory, Archiva). The search will often render groupId/artifactId and so on so a search for "util" would give you enough information to find the artifact you are looking for.

hope this helped a bit :) regards

wemu

Answer 2

Another possible approach is to look at function groups more than hierarchy.

Say project B has webapps, plugins and core librairies, then all modules share the same group id (com.mycompany.b) and artefacts are respectively named webapp-???, plugin-??? and core-???.

We also use the -parent convention mentioned earlier: therefore, the parent POM for all webapps is called webapp-parent.pom.

Answer 3

In earlier days with maven I followed the following structure which you have described:

appname
  +--- appname-module1
  +--- appname-module2
              +--- appname-module2-chhild1
              +--- appname-module2-chhild2
  +--- appname-module3

But this will become ridiculous if you get more levels.

So I decided to change my mind and now using things like:

appname
  +--- module1
  +--- module2
          +--- chhild1
                 +--- subchild1
          +--- chhild2
  +--- module3

The only thing which I change through the levels is the groupId...

appname (groupId: com.soebes.appname)
  +--- module1 (groupId: com.soebes.appname.module1)
  +--- module2 (groupId: com.soebes.appname.module2)
          +--- chhild1 (groupId: com.soebes.appname.module1.child1)
          +--- chhild2 (groupId: com.soebes.appname.module1.child2)
  +--- module3 (groupId: com.soebes.appname.module3)