Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Code Block

$groupId is a array of strings made by splitting the groupId's on "." into directories. The group org.apache.maven would then yield: org/apache/maven. This should mostly mirror the package structure in Java, though can apply to any language.

For each primary artifact there will be a POM:

  • A $artifactId-$version.$extension.pom

POMs that are exclusively parents (packaging = pom) will not have such a file howeverhave the same filename.

Secondary artifacts do not need a POM - they will reference the associated primary POM.


Code Block


The POM will always reference the primary artifact.

There can only be one POM for a groupId:artifactId combination - type does not factor into it.

The conflict ID of a dependnecy dependency is:
and the full versioned ID is

The inclusion of type is to accommodate the coexistence of subtypes: eg ejb and ejb-client.

Subtypes are created by particular mojos: eg ejb packaging will create both an ejb and an ejb-client. apidocs:package will create a JAR of the javadocs.

Dependencies will generally only reference the type corresponding to the packaging. However, in some cases, dependency on a subtype will also be required, eg:
<type>ejb-client</type>. This subtype will be mapped to

So two projects with the same artifact handler that deals with the ejb packaging so that main POM can be found.

Alternatively, we could drop the extension and always use:
instead of

This change is not currently planned.

This would require that one artifact ID only ever be associated to one packaging, which is a best practice. The only opposing use case seems to be something such as a TLD - however this is really a subtype of a taglib ID and artifact ID, but different packaging are not valid together. However, two dependencies with different types are. Therefore the common use case of having tlds with the same group/artifact ID will work, eg: