Subject: Exported From Confluence
Content-Type: text/html; charset=UTF-8
Repository Layout - Final
Repository Layout - Final
tory Layout Definition
This is the final layout for the repository available in Maven 2.x and i=
ts related Ant tasks.
This document should be incorporated into the main Maven site shortly, a=
nd a link left here as some external people have linked in directly.
Issues with the ol=
- It doesn't scale physically. The disk at ibiblio is completly trashe=
d during peak hours. I've had cases where it used a minute and a half for d=
ls in the root.
- For a user using browsing the repository through a browser it's hard=
to locate the artifacts the user want because of the number of files in th=
e directory. This might not be a really big problem if we make a applicatio=
n on top of the repository for browsing.
- The layout doesn't differ between "primary" and "seco=
ndary" artifacts. ("secondary" artifacts beeing javadoc, sou=
rces etc that do not have a POM of their own).
The current layout looks like this:
d/$type + "s"/$artifactId-$version.$type
The new layout:
Changes from the old way includes:
- Overall, the entire directory tree is much deeper. This is for both =
so that it will scale better in terms of number of files/directories in a s=
ingle directory. This will ensure that the harddisks that are hosting the r=
epository isn't thrashed like they are on ibiblio today and it will be easi=
er for a user to get a overview over a artifact, the versions of a artifact=
and the secondary artifacts it has.
- For each primary artifact there is a pom file.
- No symlinks.
For primary artifacts:
For secondary artifacts:
$groupId is a array of strings made by splitting the groupId's on
"." into directories. The group org.apache.maven would the=
org/apache/maven. This should mostly mirror the packa=
ge structure in Java, though can apply to any language.
For each primary artifact there will be a POM:
- A $artifactId-$version.pom
POMs that are exclusively parents (packaging =3D pom) will have the same=
Secondary artifacts do not need a POM - they will reference the associat=
ed 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 s=
ignature (eg .asc an ascii armoured openpgp signature)
A complete example
To ease the different uses and archival policies there will later be add=
ed 3 repository types:
- SNAPSHOT repository, where only snapshots are stored
- Archive repository, a read only repository where old releases can be=
- Release repository, where official, current releases go
Repositories can be any combination of these.
If using an archive repository, it might be considered as a deprecated r=
eository, so you could warn on uses of this for anything other than buildin=
g old releases themselves.
The POM will always reference the primary artifact.
There can only be one POM for a groupId:artifactId combination - type do=
es not factor into it.
The conflict ID of a 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 b=
oth an ejb and an ejb-client. apidocs:package will create a JAR of the java=
Dependencies will generally only reference the type corresponding to the=
packaging. However, in some cases, dependency on a subtype will also be re=
So two projects with the same group ID and artifact ID, but different pa=
ckaging are not valid together. However, two dependencies with different ty=
pes are. Therefore the common use case of having tlds with the same group/a=
rtifact ID will work, eg: