I'm currently in the process of moving some project from Ant to Maven. Conformist as I am, I want to use well-established conventions for finding groupId
and artifactId
, but I can't find any detailed conventions (there are some, but they don't cover the points I'm wondering about).
Take this project for instance, first the Java package: com.mycompany.teatimer
Tea timer is actually two words, but the Java package naming conventions forbid the insertion of underscores or hyphens, so I'm writing it all together.
I chose the groupId
identical to the package ID because I think that's a good idea. Is it?
Finally, I have to pick an artifactId
, I currently went for teatimer
. But when I look at other Maven projects, they use hyphens to split words in artifactId
s, like this: tea-timer
. But it does look weird when concatenated to the groupId
: com.mycompany.teatimer.tea-timer
.
How would you do this?
Another example:
Package name: com.mycompany.awesomeinhouseframework
groupId
: com.mycompany.awesomeinhouseframework
(?)
artifactId
: awesome-inhouse-framework
(?)
Look at More information about package names. A good way to determine the granularity of the groupId is to use the project structure. That is, if the current project is a multiple module project, it should append a new identifier to the parent's groupId. artifactId is the name of the jar without version.
In Maven terminology, an artifact is an output generated after a Maven project build. It can be, for example, a jar, war, or any other executable file. Also, Maven artifacts include five key elements, groupId, artifactId, version, packaging, and classifier.
The main difference between groupId and artifactId in Maven is that the groupId specifies the id of the project group while the artifactId specifies the id of the project. Show activity on this post. groupId uniquely identifies your project across all projects. artifactId is the name of the jar without version.
Weirdness is highly subjective, I just suggest to follow the official recommendation:
Guide to naming conventions on groupId, artifactId and version
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. Look at More information about package names.eg.
org.apache.maven
,org.apache.commons
A good way to determine the granularity of the groupId is to use the project structure. That is, if the current project is a multiple module project, it should append a new identifier to the parent's groupId.
eg.
org.apache.maven
,org.apache.maven.plugins
,org.apache.maven.reporting
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.eg.
maven
,commons-math
version
if you distribute it then you can choose any typical version with numbers and dots (1.0, 1.1, 1.0.1, ...). Don't use dates as they are usually associated with SNAPSHOT (nightly) builds. If it's a third party artifact, you have to use their version number whatever it is, and as strange as it can look.eg.
2.0
,2.0.1
,1.3.1
Your convention seems to be reasonable. If I were searching for your framework in the Maven repo, I would look for awesome-inhouse-framework-x.y.jar
in com.mycompany.awesomeinhouseframework
group directory. And I would find it there according to your convention.
Two simple rules work for me:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With