Page History

...

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)

...

Metadata will be stored at the directory level, allowing different metadata for each granularity. The file will be called maven-metadata.xml. Note that the format is the same for each directory, though it is expected that only a subset will be used for each. This is in preference to having 3 different metadata formats.

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 Information for Snapshot Version Directories

<metadata>
  <versioning>
    <snapshot>1.0.3-20051011.123014-5</snapshot>
  </versioning>
</metadata>

Plugin Information for Group Directories

...

When looking for metadata from a given repository, only the file for that repository (plugin -local merged in) will be consulted.

Keeping Up To Date

We will need to get a process running over the repository that monitors its health. We should be able to reuse repoclean in an "m2 reporting mode" to do this. It can check for md5s, sha1s and create and/or warn if they are missing, check if the metadata matches the directory, and so on.

This will be a later feature to add. It could be part of the repo management application so that errors can be shown and rectified via the web interface.