...

Status

This RFC is currently in the DRAFT state. Nothing in this RFC has been agreed or confirmed.

...

Introduction

...

Overview

Projects

The basic unit of organisation in a repository is the project coordinates. The project coordinates consist of the pair groupId:artifactId.

...

Every artifact is thus uniquely identified by its coordinates: (TODO Do we want GAVPCT or GAPVCT) 

groupId:artifactId:platformId:version:platformId:classifier:type

For artifacts that do not have a platformId the preferred form of coordinates is:

groupId:artifactId::version::classifier:type

For artifacts that do not have a classifier, the preferred form of coordinates is:

groupId:artifactId:platformId:version:platformId::type

For artifacts that do not have either a platformId or a classifier, the preferred form of coordinates is:

groupId:artifactId::version:::type

The intermediate :: characters are critical in order to disambiguate platform aware coordinates from the previous styles of coordinates:

...

Repository metadata layout

For legacy clients, we need to maintain the current maven-metadata.xml files, however, for newer clients we will provide a more flexible metadata index using JSON. In order to allow for metadata evolution, the JSON format will be subject to the following restrictions:

• Consumers must ignore unknown keys
• Producers must preserve unknown keys
• Aggregating proxies must merge all keys, where conflicts arise, the aggregating proxy will use a priority list of upstream sources to determine which value will win

The basic format will be something like:

{
  "modified":"yyyy-MM-dd'T'HH:mm:ss.SSS'Z'", // always ISO 8601 extended format in UTC timezone
  "group":[ // present if there are any artifacts deployed using the repo path as groupId
    "artifactId",
    "artifactId:platformId",
    "artifactId",
    "artifactId:platformId",
    "artifactId:platformId"
  ],
  "artifact":[ // present if there are any artifacts deployed using the repo path as groupId:artifactId[:platformId]
    "version",
    "version",
    "version",
    "version"
  ],
  "org.apache.maven:plugins":[ // this is a Maven specific key, hence namespaced
    {
      "name":"...",
      "artifactId":"...",
      "prefix":"..."
    },
    {
      "name":"...",
      "artifactId":"...",
      "prefix":"..."
    }
  ]
}

Tool specific keys must be prefixed by the top level groupId of the tool to which they are scoped. Each tool is responsible for the structure within that key and how to handle evolution of that structure.

Some examples:

https://repo.maven.apache.org/maven2/io/github/stephenc/maven/repo-metadata.json would be:

{
  "modified":"2014-01-16T09:55:43.511Z",
  "group":[
    "rfmm-maven-plugin"
  ],
  "org.apache.maven:plugins":[
    {
      "name": "Release From My Machine Maven Plugin"
      "prefix": "rfmm"
      "artifactId": "rfmm-maven-plugin"
    }
  ]
}

https://repo.maven.apache.org/maven2/io/github/stephenc/maven/rfmm-maven-plugin/repo-metadata.json would be:

{
  "modified":"2014-01-16T09:55:49.243Z",
  "artifact":[
    "1.0"
  ]
}

TODO consider a counter-proposal... the top level keys are the repository "id" and then everything else is as before. This simplifies aggregating proxies and may assist with PDT Repositories as we would then know the IDs of the content from aggregating proxies, e.g.

https://repo.maven.apache.org/maven2/io/github/stephenc/maven/repo-metadata.json would be:

{
  "central":{
    "modified":"2014-01-16T09:55:43.511Z",
    "group":[
      "rfmm-maven-plugin"
    ],
    "org.apache.maven:plugins":[
      {
        "name": "Release From My Machine Maven Plugin"
        "prefix": "rfmm"
        "artifactId": "rfmm-maven-plugin"
      }
    ]
  }
}

https://repo.maven.apache.org/maven2/io/github/stephenc/maven/rfmm-maven-plugin/repo-metadata.json would be:

{
  "central":{
    "modified":"2014-01-16T09:55:49.243Z",
    "artifact":[
      "1.0"
    ]
  }
}