We are currently trying to mavenize the existing projects in our company. We have executed a POC and are currently documenting our learnings and guidelines. I have come up the following naming convention for the maven artifacts. Please share your comments on the same

Note: In our company, projectname is always unique

For a single level multi module maven project

Parent (pom)

• groupId : org.companyname.projectname
• artifactId : org.companyname.projectname
• version : x.x.x

eg : org.companyname.projectname:org.companyname.projectname-1.0.0.pom

Modules (jar)

• groupId : org.companyname.projectname
• artifactId : org.companyname.projectname.modulename
• version : x.x.x

eg: org.companyname.projectname:org.companyname.projectname.modulename-1.0.0.jar

For a multi level multi module maven project

Parent (pom)

• groupId : org.companyname.projectname
• artifactId : org.companyname.projectname
• version : x.x.x

eg : org.companyname.projectname:org.companyname.projectname-1.0.0.pom

SubParent (pom)

• groupId : org.companyname.projectname
• artifactId : org.companyname.projectname.subcategory
• version : x.x.x

eg : org.companyname.projectname:org.companyname.projectname.subcategory-1.0.0.pom

Module (jar)

• groupId : org.companyname.projectname
• artifactId : org.companyname.projectname.subcategory.modulename
• version : x.x.x

eg : org.companyname.projectname:org开发者_运维百科.companyname.projectname.subcategory.modulename-1.0.0.jar

IMO you need not include org.companyname in the artifactId - it is just duplicating the information already present in the groupId, thus making the artifact names longer and less readable.

Update: FYI, looking through the dependencies of our project, I see plenty of similar examples, e.g.

<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>

<groupId>org.codehaus.mojo</groupId>
<artifactId>jboss-maven-plugin</artifactId>

<groupId>net.sf.barcode4j</groupId>
<artifactId>barcode4j-fop-ext-0.20.5-complete</artifactId>

<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>

<groupId>opensymphony</groupId>
<artifactId>oscache</artifactId>

<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-libs</artifactId>

<groupId>javax.resource</groupId>
<artifactId>connector-api</artifactId>

<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>

<groupId>javax.transaction</groupId>
<artifactId>jta</artifactId>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>

And then there are many where the group and artifact IDs are the same unqualified name, e.g.:

<groupId>log4j</groupId>
<artifactId>log4j</artifactId>

<groupId>velocity</groupId>
<artifactId>velocity</artifactId>

<groupId>fop</groupId>
<artifactId>fop</artifactId>

<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>

But I haven't seen any having a fully qualified group ID and an identical artifact ID (which e.g. for Log4J would be org.apache.log4j:org.apache.log4j).

Using an unqualified name for the groupId matching the artifactId (e.g. log4j) is an old deprecated practice which is not recommended: it's bad at the file system level, it generates "repository mess", it makes artifacts harder to find when browsing a repository (even if most people use a search engine nowadays).

The recommendation is to include your domain name in the groupId and I would certainly not repeat it in the artifactId (to my knowledge, Spring is NOT doing that - except maybe for OSGI artifacts?).

Here is what I use:

Parent (pom)

• groupId : org.companyname.projectname
• artifactId : root
• version : x.x.x

eg : org.companyname.projectname:root-1.0.0.pom

SubParent (pom)

• groupId : org.companyname.projectname
• artifactId : subcategory-parent
• version : x.x.x

eg : org.companyname.projectname:subcategory-parent-1.0.0.pom

Module (jar)

• groupId : org.companyname.projectname
• artifactId : modulename
• version : x.x.x

eg : org.companyname.projectname:modulename-1.0.0.jar

And I also use conventions for the <description> element to have a clean overview during reactor builds. Here is an example on a pet project:

$ mvn compile
[INFO] Scanning for projects...
[INFO] Reactor build order: 
[INFO]   Personal Sandbox - Samples - Parent POM
[INFO]   Personal Sandbox - Samples - EJB3 and Cargo Sample
[INFO]   Personal Sandbox - Tools - Parent POM
[INFO]   Personal Sandbox - Tools - Shared Verification Resources
[INFO]   Personal Sandbox - Samples - EJB3 and Cargo Sample - Services
[INFO]   Personal Sandbox - Samples - EJB3 and Cargo Sample - Functests
[INFO]   Sandbox Externals POM

This is heavily inspired by Vincent Massol's way to organize big builds like he did with XWiki or Cargo.