Applying maven groupId naming convention

Question

I am developing a number of projects (currently organized as eclipse projects). There is a core project which mainly provides the core API and some secondary implementations and abstract classes. All other projects depend on this project.

When integrating the projects into our maven repository, we got problems with the maven naming conventions. As discussed on SO, the groupId should usually be the reverse company domain name (com.example) plus the project name (com.example.foo). The maven naming conventions suggest an additional postfix for sub-projects such as plugins (com.example.foo.plugin).

In our case, we have not got plugins, but multiple (mostly independent) implementations of the API provided by the core project. Our current naming suggestion is:

• com.example.foo as the groupId of all projects, although they are split up into different java packages (com.example.foo contains the API, com.example.foo.bar contains the bar implementation)
• the project name as the artifactId, without a prefix referring to the project (bar instead of foo-bar)

The key point is that (although our projects are spread accross packages as described above) they are not really sub-projects of the API core project.

Does this suggestion comply with the maven naming conventions?

Just in case: This question is not asking for opiniated responses but for an argumentative answer to the above question.

Answer 1

I would say this is a matter of your own taste and preference.

Normally, you would group similar sets of modules under the same groupId. For example, you could have the following:

com.foo.bar:parent                          (parent pom for all projects)
com.foo.bar:core-api                        (some very core classes)
com.foo.bar:commons                         (some common classes)
com.foo.bar:io                              (some IO classes)
com.foo.bar:utils                           (some utility classes)
com.foo.bar.messaging:messaging-core        (messaging core classes)
com.foo.bar.messaging:messaging-rest-api    (REST API for messaging)
com.foo.bar.messaging:messaging-jms         (some JMS code)
com.foo.bar.web:rest-api                    (your restlets)
com.foo.bar.web:web-core                    (core classes to be used by web modules)
com.foo.bar.web:web-parent                  (a parent pom for all your web projects)
com.foo.bar.web:web-ui                      (UI stuff like css/images/js/etc)
com.foo.bar.web:web-assembly                (a web assembly that bundles all modules)
... (I hope by now you get my drift) ...

You don't necessarily need to group all modules whose classes start with a common package under the same groupId. You could do that, if you like, but that's rarely how people really use it in real life. The level of strictness and magnitude of detail is up to you, but in the case of artifacts, it usually doesn't matter that much as there's nothing to tie the package name to the groupId.

Furthermore, using a prefix for your modules is also helpful, but up to you. If you like, you could have:

com.foo.bar:bar-parent
com.foo.bar:bar-core-api
com.foo.bar:bar-commons

This is really up to you. Some will argue that if you have a groupId like com.foo.bar, then you don't need to have a bar- prefix in bar-parent. To some extent this is true. But then you could have com.foo.bar:parent and com.foo.bar.web:parent and when you're using a repository manager like Nexus, Archiva or Artifactory and you're searching for parent, (or some other common name like... commons, for example), you might end up with a rather long list of results, as opposed to bar-parent.

In the end, what matters is to what level of detail you're willing to go and what will really suit your needs. Maven allows you all the freedom you need in this regard.

Answer 2

So as I see it you have a bunch of options which follow maven naming conventions...

Foo refers to the core API and bar refers to the implementation.

1. com.example.foo (referring to the core api) as the group and then the implementation being foo-bar (convention says you include a hook back to the group in your artifact name).

2. com.example.bar as thr group and the artifact id is bar-impl or some other appropriate suffix

3. com.example.foo.bar as the group and bar-impl or some other appropriate suffix.

For 1 you are saying to the unfamiliar: the implementation is closely coupled to the API and has a closely related release cycle. When a new versio of the core API is released a version of the implementation is also released. Furthermore the implementation is a child of the core API and does not really stand alone. You are also saying the core business of bar is to be an implementation of bar and has little value apart from it (it doens't do much else).

In 2 you are saying the implementation of the core API does have it's own lifecycle and generally is not released on the same cycle as the API. Furthermore it is not a sub project of the core API and can thus stand alone. In other words, it's core business and usage is not only as an implentation of foo. If bar can have siblings this is especially attractive.

3 is a middle road between the two. It says bar has value by itself as well as having significance as an implementation of foo and also potentially allows for siblings. It slightly improves on 2 as it does provide some feedback that this artifact is an implementation of foo. Again, if bar can have siblings this makes more sense.

So I guess you'd need to select where your implementations of the API sit. The biggest driver is probably whether bar can have siblings.