src/site/apt/guides/mini/guide-central-repository-upload.apt - maven-site - Git at Google

  ------
  Guide to uploading artifacts to the Central Repository
  ------
  Jason van Zyl
  Brian Fox
  ------
  18 January 2010
  ------

 Guide to uploading artifacts to the Central Repository

  In order for users of Maven to utilize artifacts produced by your project you must deploy them to
  a remote repository. Many open source projects want to allow users of their projects who build with
  Maven to have transparent access to their project's artifacts. In order to allow for this a project
  must have their artifacts deployed to the Central Repository.


 {Requirements}

  Only releases can be uploaded to the central repository, that means files that won't change and that only depend on other files
  already released and available in the repository.

  There are some requirements for the minimal information in the POMs that are in the central repository. The updated list of requirements can be found {{{https://docs.sonatype.org/display/Repository/Central+Sync+Requirements}here}}.

 {Choosing your coordinates}

  Picking the appropriate coordinates for your project is important. See the guidelines {{{https://docs.sonatype.org/display/Repository/Choosing+your+Coordinates}here}}.

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

  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.

 * A basic sample:

 +----+

 <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>
   </scm>
   <dependencies>
     <dependency>
       <groupId>...</groupId>
       <artifactId>...</artifactId>
       <version>...</version>
     </dependency>
     ...
   </dependencies>
   <!--
   NOT ALLOWED: (see FAQ)
   <repositories></repositories>
   <pluginRepositories></pluginRepositories>
   -->
 </project>

 +----+

 * PGP Signature

  When people download artifacts from Central Maven repository, they might want to validate that these artifacts have valid PGP signatures that can be verified against a public key server. If there is no signatures, then users have no guarantee that they are downloading the original artifact.

  To improve the quality of the Central Maven 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 hkp://pgp.mit.edu . Read {{{https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+With+Maven}How to Generate PGP Signatures with Maven}} 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 Central. 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.
  {{{http://repo1.maven.org/maven2/javax/activation/activation/1.0.2/activation-1.0.2.pom}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 dev.java.net, what should I use as groupId?

  If your project name is <<<foo>>> at SourceForge, then <<<net.sf.foo>>>. If it's <<<foo>>> at dev.java.net, then <<<net.java.dev.foo>>>

  []

 {Sync'ing your own repository to the central repository automatically}

  This used to be the preferred process but 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 serveral 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.

  Rsyncs 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 at repo-maintainers@maven.apache.org

  []

 {Approved Forges}

  Instead of maintaining your own repository rsync feed, we now encourage projects to use an approved Forge that provides repository hosting. (Not all of them require code to be hosted at the same Forge) The aggregation of projects into single larger feeds will allow us to sync faster and more often, and the checks provided by approved Forges increases the quality of metadata for everyone.


  Currently approved Forges:

   * {{{http://incubator.apache.org/}Apache}} (open to Apache Projects)

   * {{{http://codehaus.org/customs/selection.html}Codehaus}} (open to Codehaus Projects)

   * {{{http://nexus.sonatype.org/oss-repository-hosting.html}Sonatype Forge}} (open to any OSS Project)

   * {{{http://www.fusesource.org/forge/}Fusesource Forge}} (Focused on FUSE related projects)

   * {{{http://www.nuiton.org}Nuiton.org}}

  []
 {Manual upload of artifacts}

  See {{{https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+Maven+Central}here}} for information about the new process to get artifacts loaded into Central. The new process is mostly automated with turnaround time averaging 1 Business day.
	------
	Guide to uploading artifacts to the Central Repository
	------
	Jason van Zyl
	Brian Fox
	------
	18 January 2010
	------

	Guide to uploading artifacts to the Central Repository

	In order for users of Maven to utilize artifacts produced by your project you must deploy them to
	a remote repository. Many open source projects want to allow users of their projects who build with
	Maven to have transparent access to their project's artifacts. In order to allow for this a project
	must have their artifacts deployed to the Central Repository.


	{Requirements}

	Only releases can be uploaded to the central repository, that means files that won't change and that only depend on other files
	already released and available in the repository.

	There are some requirements for the minimal information in the POMs that are in the central repository. The updated list of requirements can be found {{{https://docs.sonatype.org/display/Repository/Central+Sync+Requirements}here}}.

	{Choosing your coordinates}

	Picking the appropriate coordinates for your project is important. See the guidelines {{{https://docs.sonatype.org/display/Repository/Choosing+your+Coordinates}here}}.

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

	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.

	* A basic sample:

	+----+

	<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>
	</scm>
	<dependencies>
	<dependency>
	<groupId>...</groupId>
	<artifactId>...</artifactId>
	<version>...</version>
	</dependency>
	...
	</dependencies>
	<!--
	NOT ALLOWED: (see FAQ)
	<repositories></repositories>
	<pluginRepositories></pluginRepositories>
	-->
	</project>

	+----+

	* PGP Signature

	When people download artifacts from Central Maven repository, they might want to validate that these artifacts have valid PGP signatures that can be verified against a public key server. If there is no signatures, then users have no guarantee that they are downloading the original artifact.

	To improve the quality of the Central Maven 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 hkp://pgp.mit.edu . Read {{{https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+With+Maven}How to Generate PGP Signatures with Maven}} 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 Central. 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.
	{{{http://repo1.maven.org/maven2/javax/activation/activation/1.0.2/activation-1.0.2.pom}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 dev.java.net, what should I use as groupId?

	If your project name is <<<foo>>> at SourceForge, then <<<net.sf.foo>>>. If it's <<<foo>>> at dev.java.net, then <<<net.java.dev.foo>>>

	[]

	{Sync'ing your own repository to the central repository automatically}

	This used to be the preferred process but 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 serveral 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.

	Rsyncs 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 at repo-maintainers@maven.apache.org

	[]

	{Approved Forges}

	Instead of maintaining your own repository rsync feed, we now encourage projects to use an approved Forge that provides repository hosting. (Not all of them require code to be hosted at the same Forge) The aggregation of projects into single larger feeds will allow us to sync faster and more often, and the checks provided by approved Forges increases the quality of metadata for everyone.



	Currently approved Forges:

	* {{{http://incubator.apache.org/}Apache}} (open to Apache Projects)

	* {{{http://codehaus.org/customs/selection.html}Codehaus}} (open to Codehaus Projects)

	* {{{http://nexus.sonatype.org/oss-repository-hosting.html}Sonatype Forge}} (open to any OSS Project)

	* {{{http://www.fusesource.org/forge/}Fusesource Forge}} (Focused on FUSE related projects)

	* {{{http://www.nuiton.org}Nuiton.org}}

	[]
	{Manual upload of artifacts}

	See {{{https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+Maven+Central}here}} for information about the new process to get artifacts loaded into Central. The new process is mostly automated with turnaround time averaging 1 Business day.