Skip to content

Coordinates

Choose your coordinates⚓︎

The groupId identifies your project uniquely across all projects and you control this section of the overall name-space. Similar to the Java package naming convention it reuses the domain name system in a reversed manner. This means that if you are the owner or maintainer of a domain name, you can use any groupId starting with the reverse domain name and as many subsections as you desire.

E.g., if you control example.com, you can use any groupId starting with com.example e.g. com.example.domain, com.example.testsupport and so on. Other examples are

  • www.springframework.org -> org.springframework
  • subdomain.example.com -> example.com
  • github.com/yourusername -> io.github.yourusername

Tip

When we grant permissions at the top-level groupId, like io.github.example, you can publish any components under that groupId or any sub-groups that look like io.github.example.mysubgroup1 or io.github.example.android

For projects with artifacts already uploaded to the Central Repository it can be equal to the one used previously, even if that violates the convention.

A good way to determine the granularity of the groupId is to use the project structure. That is, if the current project is a multimodule project, it should append a new identifier to the parent's groupId - e.g., org.apache.maven, org.apache.maven.plugins, org.apache.maven.reporting.

The artifactId is the name of your project itself. You can choose whatever name you want with lowercase letters and no strange symbols. For longer names separation with dashes is common - maven-core , commons-math

For version we suggest to follow usage semantic version numbers to convey a meaningful number to your users and allow an understandable order of versions. However there is no specific requirement for your version number.

Supported Code Hosting services for Personal groupId⚓︎

As we know that sometimes it's difficult to manage an specific domain for a small project, we support the domains linked to personal accounts in the Code Hosting services below, so if your use them a simple verification will be asked to prove ownership:

For the user myusername on each service

Service Example groupId Link to the hosting service Documentation
GitHub io.github.myusername https://pages.github.com/
GitLab io.gitlab.myusername https://about.gitlab.com/stages-devops-lifecycle/pages/
Gitee io.gitee.myusername https://gitee.com/help/articles/4136
Bitbucket io.bitbucket.myusername https://support.atlassian.com/bitbucket-cloud/docs/publishing-a-website-on-bitbucket-cloud/
SourceForge io.sourceforge.myusername https://sourceforge.net/p/forge/documentation/Project%20Web%20Services/

Policy for Assigning groupIds to 3rd party artifacts⚓︎

This information is for handling 3rd party projects which don't want to upload their artifacts directly into The Central Repository. If you want to deploy your own project to The Central Repository, please use OSSRH Guide.

While most projects understand the importance of publishing artifacts to Central, there are still a few projects out there that don't have the same appreciation. When a project refuses to upload artifacts to Central, for whatever reason, as long as the license permits, we encourage people to submit artifact bundles to Central themselves.

If you want to get a specific library into the Central repository, all you need to do is sign up for an account on https://issues.sonatype.org, create an artifact bundle, and upload it to the staging repository. Sonatype will perform some due diligence to make sure that the artifact has a license compatible with unrestricted distribution, and we will then promote the uploaded artifacts to the Central Maven repository.

Once you've uploaded your bundle, Nexus Repository Manager sends a message to Sonatype's administrators. We will then perform a few checks on the artifact. We will check to see if the artifact is already published on Central. We may also send you a few questions to make sure that you have tried to contact the original project to get them to publish the artifacts, but we will respond within a business day to your bundle upload. If the bundle upload is promoted you will receive an email confirming the promotion. If the bundle upload is dropped, you will also receive an email from Nexus Repository Manager that tells you why the bundle was dropped.

Sonatype is still convinced that artifacts are best managed by the projects that create them, but, in more than a few cases, we've run into projects that refuse to answer the call of the community. If you depend on a project that does not publish artifacts to Central, or if they seem to be inactive, please take advantage of the ability to upload your own artifact bundles.