Central Sync Requirements

Skip to end of metadata
Go to start of metadata

To Improve The Central Repository and the Supporting the Maven Ecosystem, all artifacts to be synced to central must meet these requirements.

  • Project POM has the following elements.
    • <modelVersion>
    • <groupId>
    • <artifactId>
    • <version>
    • <packaging>
    • <name>
    • <description>
    • <url>
    • <licenses>
    • <scm><url>
    • <scm><connection>
    • <developers>
  • If the project packaging is jar, and the jar file contains java classes, there must be a -javadoc.jar for main artifact.
  • If the project packaging is jar, and the jar file contains java classes, there must be a -sources.jar for main artifact.
  • All project artifacts are signed using GPG, and the public key is distributed to hkp://pool.sks-keyservers.net/. For more information, please refer to How To Generate PGP Signatures With Maven.
Sources and Javadoc
If, for some reason (for example, license issue or it's a Scala project), you can not provide -sources.jar or -javadoc.jar, please make fake -sources.jar or -javadoc.jar with simple README inside to pass the checking. We don't want to disable the rules because some people tend to skip it if they have an option.

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 repository as part of the process we open up the doors to new ideas that involve unified access to projects.

We also ask for license now because it is possible that your project's license may change in the course of its life time and we are trying create tools to help normal people 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.

Besides, we discourage putting release repository/pluginRepository in your POM. In ideal conditions, all your dependencies should be already in central and central repository is self-contained. Otherwise people's build might break because of missing dependencies. If some of your dependencies are not in central, please upload them using our 3rd-party artifacts bundle upload service.

Brian has written 2 posts from different angles:

a complete sample POM
 <project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.apache.maven</groupId>
  <artifactId>maven</artifactId>
  <packaging>jar</packaging>
  <name>Maven core</name>
  <version>2.0</version>
  <description>The maven main core project description</description>
  <url>http://maven.apache.org</url>
  <licenses>
    <license>
      <name>The Apache Software License, Version 2.0</name>
      <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url>
      <distribution>repo</distribution>
    </license>
  </licenses>
  <scm>
    <url>http://svn.apache.org/viewcvs.cgi/maven</url>
    <connection>http://svn.apache.org/viewcvs.cgi/maven</connection>
  </scm>
  <developers>
    <developer>
      <id>...</id>
      <name>...</name>
      <email>...</email>
    </developer>
  </developers>
  <dependencies>
    <dependency>
      <groupId>...</groupId>
      <artifactId>...</artifactId>
      <version>...</version>
    </dependency>
    ...
  </dependencies>
  <!--
  AVOID RELEASE REPOSITORY/PLUGINREPOSITORY:
  <repositories></repositories>
  <pluginRepositories></pluginRepositories>
  -->
</project>
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.