From http://maven.apache.org/guides/mini/guide-naming-conventions.html:
groupid will identify your project uniquely across all projects, so we need to enforce a naming schema. It has to follow the package name rules, what means that has to be at least as a domain name you control, and you can create as many subgroups as you want
artifactId is the name of the jar without version. If you created it then you can choose whatever name you want with lowercase letters and no strange symbols. If it’s a third party jar you have to take the name of the jar as it’s distributed.
If artifactId is the name of the jar, it has to be more or less unique. For instance you can not deploy two jars with different groupId but the same artifactId in a web-inf/lib directory of a web application. Therefore one should avoid generic artifactIds like ‘common’ etc..
Consider a project with layer and slice architecture. The base packages can grouped like:
| Slice 1 | Slice 2 | Slice 3 | |
|---|---|---|---|
| Layer 1 | m.a.x | m.b.x | m.c.x |
| Layer 2 | m.a.y | m.b.y | m.c.y |
| Layer 3 | m.a.z | m.b.z | m.c.z |
Examples
a=common, b = shopping, c = catalog, x = ui, y = core, z = data
-> jar names: m.x.jar or m.a.x.jar
-> maven groupId:artifactId : m:a.x or m:m.a.x
If m.a.z consists of more modules:
In order to have unique jar names, the the jar name should be the jar’s base package name (or the bundle symbolic name).
- The maven artifactId is the base package name.
- The maven groupId is part of the artifactId.
- Split packages are not allowed and should not be neccesary.
This kind of naming conventions should play nice together with Java 9 modules, see also http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html