ansaurus

Question

Answer 1

+3 A:

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

Péter Török 2010-06-30 14:25:42

Thanks Péter. That did make sense but I was looking at the artifacts from spring and maven repositories. They all followed a similar naming convention so I too decided to follow the crowd ;-)

Manoj 2010-06-30 14:35:16

@Manoj, I apparently see a very different sample of IDs - see my update (and of course, decide four yourself :-)

Péter Török 2010-06-30 14:59:03

official maven guide for naming conventions agrees with Peter :-)http://maven.apache.org/guides/mini/guide-naming-conventions.html

Manoj 2010-06-30 21:01:11

Answer 2

A:

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.

Pascal Thivent 2010-06-30 15:43:26

ansaurus

tags:

views:

answers:

Naming convention for Maven Artifacts

For a single level multi module maven project

Parent (pom)

Modules (jar)

For a multi level multi module maven project

Parent (pom)

SubParent (pom)

Module (jar)

Parent (pom)

SubParent (pom)

Module (jar)

related questions