Applying the maven groupId naming convention

Question

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

When integrating projects into our maven repository, we have problems with maven naming conventions. As discussed in SO, groupId should usually be the return company domain name ( com.example ) plus the project name ( com.example.foo ). The maven naming conventions offer an additional postfix for subprojects such as plugins ( com.example.foo.plugin ).

In our case, we do not have plugins, but several (mostly independent) API implementations provided by the main project. Our current naming convention:

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

The key point is that (although our projects are distributed in packages as described above), they are not really sub-projects of the main API project.

Does this assumption comply with the maven naming conventions?

Just in case: this question does not ask for reviews, but a reasoned answer to the specified question.

Answer 1

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

Usually you should group similar sets of modules under the same groupId . For example, you might 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 do not need to group all modules whose classes begin with a common package under the same groupId . You could do it if you want, but it's rare how people really use it in real life. The level of rigor and detail is up to you, but in the case of artifacts this usually does not matter much since there is nothing to associate the package name with groupId .

In addition, using a prefix for your modules is also useful, but up to you. If you want, you can:

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

It really is up to you. Some argue that if you have groupId as com.foo.bar , you do not need to have the 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 use a storage manager like Nexus, Archiva or Artifactory, and you are looking for parent (or some other common name, for example ... commons , for example), you can get a rather long list of results, rather than bar-parent .

In the end, what matters is at what level of detail are you ready to go and what really suits your needs. Maven allows you all the freedom you need in this regard.

Answer 2

So, as I see it, you have many options that follow the maven naming conventions ...

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

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

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

• com.example.foo.bar as a group and bar-impl or some other appropriate suffix.

For 1 you say unfamiliar: the implementation is closely related to the API and has a close release cycle. When a new version of the core API is released, an implementation version is also released. In addition, the implementation is a child base of the API and is not truly lonely. You also say that the main business of the bar should be the implementation of the bar and does not really matter besides it (it no longer does anything else).

In 2, you say that the implementation of the core API has its own life cycle and is not generally released in the same cycle as the API. In addition, it is not a subproject of the core API, and thus can remain autonomous. In other words, the core business and its use is not only the introduction of foo. If a bar can have brothers and sisters, this is especially attractive.

3 - middle road between them. He says the bar has value in itself, and also matters as a foo implementation, and also potentially allows siblings. It improves a bit by 2, as it gives some feedback that this artifact is an implementation of foo. Again, if a bar can have brothers and sisters, that makes more sense.

So, I think you will need to choose where your API implementations sit. The biggest driver is probably whether the bar has siblings.

Answer 3

I would say that all artifacts are in the same group. But if necessary, use the subproject template.

For example, spring has all the main artifacts in one group, org.springframework . This includes the core of spring and the JMS, ORM, and WMV subprojects. But then larger subprojects such as spring boot have a separate groupId, org.springframework.boot . I would say that this is a good example.

Answer 4

Naming things is really important, and names should immediately convey important information. For this reason, the agreements that my company used indicate that the group identifier should be the same for all implementations of a particular thing: each Id group is com.example.foo, because all of them are its implementations. Project names should refer to the interface and be transferred with a name for their specific implementation, with the main parent pom marked as "parent":

 com.example.foo:parent com.example.foo:foo-bar com.example.foo:foo-bat com.example.foo:foo-baz 

Thus, you can tell at a glance the names of how these things are related, and the names of artifacts also individually mean that they are different types of foo. It also means that importing into Java code follows exactly the same structure. It also makes import very clear and understandable in Java code.