Repository Metadata
Currently we have a number of small metadata files:
- RELEASE.version.txt (detemines the latest release of the artifact)
- SNAPSHOT.version.txt (determines the timestamp/build# of the latest build of the artifact)
- LATEST.version.txt (determines the latest build of the artifact, whether it be a timestamp or a release)
- plugins.xml (maps plugin prefixes to artifact Id within the group)
With the advent of version ranges, this will require use to get a list of versions for an artifact also. This has gotten to "critical mass" of metadata that we should move to handling general directory metadata.
We can safely remove reading of plugins.xml now since there hasn't been a release cut that uses it, and there are not significant amounts to convert in the repo. We should continue to read the others, but deprecate it.
Location of metadata
Metadata will be stored at the directory level, allowing different metadata for each granularity. The file will be called maven-metadata.xml
Version Information for Artifact Directories
<metadata> <versioning> <release>1.0.2</release> <latest>1.0.3-SNAPSHOT</latest> <snapshot>1.0.3-20051011.123014-5</snapshot> <versions> <version>1.0.0-SNAPSHOT</version> <version>1.0.0</version> <version>1.0.1-SNAPSHOT</version> <version>1.0.1</version> <version>1.0.2-SNAPSHOT</version> <version>1.0.2</version> <version>1.0.3-SNAPSHOT</version> </versions> </versioning> </metadata>
Version Ordering
The latest and even release metadata may not be needed if we are honoring a versionining scheme as determined from the POM - however, if that scheme changes over time the version order might not be consistent so it is worth keeping here.
It is also possible that the list be ordered and the last is used for latest (and the last non-snapshot for release).
Plugin Information for Group Directories
<metadata> <groupId>org.codehaus.mojo</groupId> <plugins> <plugin> <prefix>myPlugin</prefix> <artifactId>myPlugin-maven-plugin</artifactId> </plugin> </plugins> </metadata>
Local metadata storage
As changes made locally may need to be merged with the remote version, they will be stored in maven-metadata-local.xml
alongside the other file which is downloaded from the remote repository (when newer).
maven-metadata-local.xml
will be merged with maven-metadata.xml
with the local changes being considered newer regardless of time. If this later becomes an issue we can timestamp each entry.
This means that multiple local changes can be made, but when it comes to deploy one, all that is needed is:
- check
maven-metadata.xml
is up to date - update
maven-metadata.xml
- deploy
maven-metadata.xml
- remove entry from
maven-metadata-local.xml
For removals, they should be removed from maven-metadata.xml
directly in the local repository. This will not be overwritten until the remote file changes so is persistent long enough and avoids having to have "deleted" semantics in maven-metadata-local.xml
.