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>https://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 should 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.

The Central Repository requires PGP signatures for all artifacts (all files except checksums) with a public key available from a key server like https://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 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 modify a third party project, that patched version becomes your project and therefore should be only be publicly distributed under a groupId you control, never under com.foo. (If you're only distributing to a private repository inside your organization, do whatevcer's convenient.) When changing the group ID, you should also change the Java package to avoid classpath conflicts and split package issues. See JLBP 6.

• 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

We encourage projects to use an approved repository hosting location.

Currently approved repository hosting locations:

• Apache Software Foundation (for all Apache projects)

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.