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)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.
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.