groupId

The groupId will identify your project uniquely across all projects, so we need to enforce a naming schema. For projects with artifacts already uploaded to the Central Repository it can be equal to the one used previously, but for new projects it has to follow the package name rules, which means that has to be at least as a domain name you control, and you can create as many subgroups as you want. There are a lot of poorly defined package names so you must provide proof that you control the domain that matches the groupId. Provide proof means that the project is hosted at that domain or it's owned by a member, in that case you must give the link to the registrar database (whois) where the owner is listed and the page in the project web where the owner is associated with the project. eg. If you use a com.sun.xyz package name we expect that the project is hosted at http://xyz.sun.com.

Look at More information about package names. Check also the guide about Maven naming conventions.

Examples:

• www.springframework.org -> org.springframework
• oness.sf.net -> net.sf.oness

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>

FAQ and common mistakes

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

  Yes, the central repository must be self contained, which means that all your dependencies must already be in the central repository. You need to remove the repositories and pluginRepositories entries and make sure your project still builds when your local repository cache is empty.

  The only exception allowed is when a dependency can not be distributed from the central repository due to the 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 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

Step 1: Create an upload bundle

Use the repository plugin provided with the standard Maven distribution to create an upload bundle:

mvn repository:bundle-create

The bundle will be created in your target directory with the name: ${pom.artifactId}-${pom.currentVersion}-bundle.jar

If you want to include a jar with java sources in your upload (recommended, unless your license doesn't allow sources to be redistributed) the command to run is:

Note: due to a bug in repository:bundle-create you will need to manually add the javadoc jar to the bundle jar, using zip or any other compression program.

mvn source:jar javadoc:jar repository:bundle-create

If you are not using Maven as your build system, and want something uploaded to the Central Repository then you just need to make a bundle jar manually. Please use the jar executable, not zip, pkzip or equivalent. The bundle should have the following content:

pom.xml
foo-1.0.jar (or whatever artifact is referred to in the pom.xml)
foo-1.0-sources.jar (optional, jar containing java sources)
foo-1.0-javadoc.jar (optional, jar containing javadocs)

The names of the jar files inside the bundle must be built from the <artifactId> and <version> in the pom.xml file, like this:

${artifactId}-${version}.jar
${artifactId}-${version}-sources.jar  (optional)
${artifactId}-${version}-javadoc.jar  (optional)

Note: the bundle will be read by a script, so it must follow the above format.

Be sure to always check previous versions of the POMs in the repository to use the information already there as a base.

Step 2: Posting the request

Post your request to JIRA. Make sure that the project is "Maven Upload Requests" and the issue type is "Wish". In the Description field, you must write the URL to the upload bundle. If you're uploading more than one bundle please add all the URLs under the same issue. Then leave a blank line and provide the following information:

• A URL where the project can be found.
• If you are one of its developers, a URL where your name or email can be found inside the project site.

This will speed up the uploading process.

You can place any additional comments in the following paragraph. So the Description field might look like:

http://wiggle.sourceforge.net/downloads/wiggle-1.0-bundle.jar

http://wiggle.sourceforge.net
http://wiggle.sourceforge.net/team-list.html

I'm a developer in wiggle, please upload!

or

http://wiggle.sourceforge.net/downloads/wiggle-1.0-bundle.jar

http://wiggle.sourceforge.net
http://wiggle.sourceforge.net/team-list.html

I'm a developer in wiggle, and want to use the org.wiggle groupId
I own wiggle.org domain, you can see my name in
http://reports.internic.net/cgi/whois?whois_nic=wiggle.org&type=domain
or you can see the project web page in www.wiggle.org

Manual process FAQ and common mistakes

• I use parent POMs. How do I include them in the bundle?

  You can't. You need to use the automated synchronization process noted above.

• I want to upload several bundles. Do I need to create a JIRA issue for each one?

  No, please ignore the Bundle URL field in this case. Just put the URLs of all the bundles in the Description or Comments fields of one single JIRA issue.