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] (http://docs.oracle.com/javase/tutorial/java/package/namingpkgs.html) it reuses the domain name system in a reversed manner. This means that if you are controlling a domain name you can use any groupId starting with the reverse domain name and subsections and create as many 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
- oness.sf.net -> net.sf.oness
- github.com/yourusername -> com.github.yourusername
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.
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 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.