Repository Layout Definition
This is the proposed final layout for the repository available in Maven 2.x repository. This is current as at March 15, 2005 and all comments prior to that have been considered to be incorporatedand its related Ant tasks.
Info |
---|
This document should be incorporated into the main Maven site shortly, and a link left here as some external people have linked in directly. |
Issues with the old layout
...
Code Block |
---|
/$groupId/$type + "s"/$artifactId-$version.$type |
The
...
new layout:
Changes from the old way includes:
...
Code Block |
---|
/$groupId[0]/../$groupId[n]/$artifactId/$version/$artifactId-$version-$extra$classifier.$extension |
$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.
For each file that is the repository there must be a file containing the checksum of the file, typically md5 or sha1. There may also be a digital signature (eg .asc an ascii armoured openpgp signature)
A complete example
In the /org/codehaus/plexus
directory:
Code Block |
---|
plexus/ /plexus-RELEASE.version.txt /plexus-RELEASE.version.txt.md5 plexus/1.0/ /plexus-1.0.pom /plexus-1.0.pom.md5 plexus-container/ /plexus-container-RELEASE.version.txt plexus-container/0.15-SNAPSHOT/ /plexus-container-0.15-200407151214.jar /plexus-container-0.15-200407151214.jar.md5 /plexus-container-0.15-200407151214.jar.sha1 /plexus-container-0.15-200407151214.pom /plexus-container-0.15-200407151214.jar.pom.md5 /plexus-container-0.15-200407151315.jar /plexus-container-0.15-200407151315.jar.md5 /plexus-container-0.15-200407151315.jar.pom /plexus-container-0.15-200407151315.jar.pom.md5 /plexus-container-0.15-SNAPSHOT.version.txt /snapshot-versionplexus-container-0.15-SNAPSHOT.version.txt.md5 plexus-container/0.16-SNAPSHOT/ /plexus-container-0.16-200407151612.jar /plexus-container-0.16-200407151612.jar.md5 /plexus-container-0.16-200407151612.jar.pom /plexus-container-0.16-200407151612.jar.pom.md5 /plexus-container-0.16-SNAPSHOT.version.txt /snapshot-versionplexus-container-0.16-SNAPSHOT.version.txt.md5 plexus-container/0.15/ /plexus-container-0.15.jar /plexus-container-0.15.jar.md5 /plexus-container-0.15.jar.pom /plexus-container-0.15.jar.pom.md5 /plexus-container-0.15-javadoc.jar /plexus-container-0.15-javadoc.jar.md5 /plexus-container-0.15-javasrc.jar /plexus-container-0.15-javasrc.jar.md5 plexus-container/0.16/ /plexus-container-0.16.jar /plexus-container-0.16.jar.md5 /plexus-container-0.16.jar.pom /plexus-container-0.16.jar.pom.md5 /plexus-container-0.16-javadoc.jar /plexus-container-0.16-javadoc.jar.md5 /plexus-container-0.16-javasrc.jar /plexus-container-0.16-javasrc.jar.md5 /plexus-container-0.16-src.tar.gz /plexus-container-0.16-src.tar.gz.md5 /plexus-container-0.16-bin.tar.gz /plexus-container-0.16-bin.tar.gz.md5 some-ejb/1.0/ /some-ejb-1.0.jar /some-ejb-1.0.jar.md5 /some-ejb-1.0.jar.pom /some-ejb-1.0.jar.pom.md5 /some-ejb-1.0-client.jar /some-ejb-1.0-client.jar.md5 |
Different Repositories
To ease the different uses and archival policies there will later be added 3 repository types:
...
Repositories can be any combination of these.
If using an archive repository, it might be considered as a deprecated reository, so you could warn on uses of this for anything other than building old releases themselves.
POM referencing
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 dependency is:
groupId:artifactId:type
and the full versioned ID is
groupId:artifactId:type:version
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>.
So two projects with the same group 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:
/taglibs/1.2.2/taglibs-1.2.2.pom
/taglibs/1.2.2/taglibs-1.2.2.jar
/taglibs/1.2.2/taglibs-1.2.2.tld
/taglibs/1.2.2/taglibs-html-1.2.2.jar