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.
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. At least these must be present:
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, what 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:
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.
<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>
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.
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.
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
This is the preferred process. You first have to setup your project to deploy to a remote repository.
You must make sure the remote repository server has rsync or rsync over ssh, there are free services like Sourceforge that provide you ssh server access.
After you are able to deploy to your remote repository make sure you only deploy releases. Then you need to provide us the following information in a comma delimited format
The comma delimited version would be something like this. Note that the two last columns are for internal purposes, so you can omit them.
"org.apache.maven","mavensync@shell.sourceforge.net:/home/groups/m/ma/maven-js-plugin/htdocs/m2repo","rsync_ssh","John Doe","doe@doe.com",, "org.apache.maven","rsync://maven2.hortis.ch/releases","rsync","John Doe","doe@doe.com",,
You can see the list of automatically synchronized repositories.
Open an issue in JIRA with the information (in the comma delimited format), and we'll add it to the list of automatically synced repositories.
Make sure you provide proof of owning the domain that matches the groupId (see groupId considerations above). Proof means either the server to sync from has a name under that domain, your name shows up in a prominent place in the domain or you provide a link to a whois database where your name shows up as the domain owner.
If you are using ssh in your own server you need to add the maven public key to the authorized ones to allow us to log in to the machine.
Remember to subscribe to the repo-maintainers mailing list. (Or watch the Atom feed.)
Important: nothing is deleted or changed in the Central Repository after it is synced (except maven-metadata.xml files).
If the third party project is not willing to provide a repository to sync from, and you are a regular user of Maven and the third party project, the answer is yes. You can set up a repository as if the project were yours (see instructions above). Please create a JIRA issue first describing what you are trying to do and why, and you may be designated the "unofficial" mantainer of the repository section associated with that project, and you will be responsible of publishing the new releases for that project in your repository if other users request it. You can opt out at any time.
Note that this manual process is time consuming and will only be accepted for a limited number of requests. If you want to upload frequently read the section above about automatic sync.
Estimated process time is FOUR WEEKS. If you want to use the manual process, that is the estimated time to process if no problems are detected. It means that for each version you release and want to upload to the central repository you will have to wait that time. If a problem is detected, it will be noted in the JIRA issue and you will wait again until the next time the issues are processed.
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.
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:
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
You can't. You need to use the automated synchronization process noted above.
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.
The following sites automatically sync their project repository with the central one. If you want a project from any of these sites to be uploaded to the Central Repository you'll have to contact their project maintainers.
The scripts to make the upload to the repository are at https://svn.apache.org/repos/asf/maven/repository-tools/trunk in the src/bin directory.
Those scripts are checked out to repo1.maven.org in the directory /home/maven/bin, so after logging in as the user maven you can go to the directory bin/bundle-upload and run
./deploy-bundle bundle_URL [groupId] [version] [classifier]
That script will download the bundle, decompress it and show the POM. You have to make sure that the POM is correct. The script uses the command less to show the POM. Use the space key to step through it to the end. The press the q key to proceed. After that a summary with groupId, artifactId and version will be shown, and whether or not the group already exists. This is useful as we have to be careful creating new groups, making sure they follow the conventions and that they don't already exist with another name. If the POM is not correct or there's any doubt the upload must be aborted with Ctrl-C, and a comment posted in the upload request in JIRA. If there's no response from the reporter within one month the request will be closed as "Incomplete".
If groupId and version are not specified in the command line, the script will try to get the values from the POM. It won't work if the POM extends another POM and those elements are not present in the POM included in the bundle.
Things to remember: