Explanation

Some folks have asked "why do we require all this information in the POM for deployed artifacts?", so here's a small explanation.

The POM being deployed with the artifact is part of the process to make transitive dependencies a reality in Maven. The logic for getting transitive dependencies working is really not that hard, the problem is getting the data. The other applications that are made possible by having all the POMs available for artifacts are vast, so by placing them into the Central Repository as part of the process we open up the doors to new ideas that involve unified access to project POMs.

We ask for the license because it is possible that your project's license may change in the course of its lifetime, and we are trying to create tools to help sort out licensing issues. For example, knowing all the licenses for a particular graph of artifacts, we could have some strategies that would identify potential licensing problems.

A basic sample:

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.apache.maven</groupId>
  <artifactId>maven</artifactId>
  <version>2.0</version>
  <packaging>jar</packaging>

  <name>Maven core</name>
  <description>The maven main core project description</description>
  <url>http://maven.apache.org</url>

  <licenses>
    <license>
      <name>Apache License, Version 2.0</name>
      <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url>
      <distribution>repo</distribution>
    </license>
  </licenses>

  <scm>
    <url>https://svn.apache.org/viewvc/maven</url>
  </scm>

  <dependencies>
    <dependency>
      <groupId>...</groupId>
      <artifactId>...</artifactId>
      <version>...</version>
    </dependency>
    ...
  </dependencies>

  <!--
  NOT RECOMMENDED: (see FAQ)
  <repositories></repositories>
  <pluginRepositories></pluginRepositories>
  -->
</project>

PGP Signature

When people download artifacts from the Central Repository, they might want to verify these artifacts' PGP signatures against a public key server. If there are no signatures, then users have no guarantee that they are downloading the original artifact.

To improve the quality of the Central Repository, we require you to provide PGP signatures for all your artifacts (all files except checksums), and distribute your public key to a key server like http://pgp.mit.edu. Read Working with PGP Signatures for more information.

FAQ and common mistakes

• I have other repositories or pluginRepositories listed in my POM, is that a problem?

  At present, this won't preclude your project from being included, but we do strongly encourage making sure all your dependencies are included in the Central Repository. If you rely on sketchy repositories that have junk in them or disappear, it just creates havok for downstream users. Try to keep your dependencies among reliable repos like Central, Jboss, etc.

• What about artifacts that can't be distributed because of their license?

  In that case only the POM for that dependency is required, listing where the dependency can be downloaded from. See an example.

• I have a patched version of the foo project developed at foo.com, what groupId should I use?

  When you patch / modify a third party project, that patched version becomes your project and therefore should be distributed under a groupId you control as any project you would have developed, never under com.foo. See above considerations about groupId.

• My project is hosted at a project hosting service like SourceForge or Github, what should I use as groupId?

  If your project name is foo at SourceForge, you can use net.sf.foo. If your username is bar on Github, you can use com.github.bar. You can also use another reversed domain name you control. The group ID does not have to reflect the project host.

Approved Repository Hosting

Instead of maintaining repository rsync feeds for each projects, we now encourage projects to use an approved repository hosting location.

Currently approved repository hosting locations:

• Apache Software Foundation (for all Apache projects)
• see the full list

Automatic publication will be provided for Forges that provide hosting services for OSS projects and other large project repositories that meet certain minimum criteria such as validation of PGP keys and pom contents as defined above. If you are interested in becoming an approved Forge, contact us.

Other Projects

The easiest way to upload another project is to use the Open Source Software Repository Hosting (OSSRH), which is an approved repository provided by Sonatype for any OSS Project that wants to get its artifacts into the Central Repository.

Explanations

Having each project maintain its own repository with rsync to the Central Repository was the preferred process until January 2010. However, we are no longer accepting rsync requests on a per project basis.

Over time, we have learned that this process is not scalable. Many of the projects being synced release very infrequently, yet we have to hit hundreds of servers several times a day looking for artifacts that don't change. Additionally, there is no good mechanism currently for validating the incoming data via the rsync, and this leads to bad metadata that affects everyone.

The aggregation of projects into larger feeds allows us to sync faster and more often, and ensuring these locations perform sufficient checks increases the quality of metadata for everyone.