Choosing your 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 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, you can use any groupId starting with com.example e.g. com.example.domain, com.example.testsupport and so on. Other examples are

  • -> org.springframework
  • -> net.sf.oness
  • -> 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.

Policies for Assigning groupIds to 3rd party artifacts

  1. Responsibility earns Authority: When you define a groupId and start producing artifacts, it should be unique and I should expect to be responsible for those artifacts. Responsibility comes with some authority over what goes in there. If I were junit, I wouldn't want some fork (a fork that likely exists because I disagreed with the changes) to appear inside my space.

  2. Authority is Earned by Responsibility (meritocracy): If I am not representing my artifacts on the Central Repository, and someone else is willing to do so responsibly, then they effectively inherit that authority.

  3. Favor the Project: If a projects decides to start producing artifacts, we welcome and encourage that and they will inherit the group.

So here if the project has no current artifacts on the Central Repository then the process should be:1. Try to get/assist them in providing artifacts themselves. 2. If they don't, then we will accept uploads on their behalf using an appropriately named groupId (ie one "owned" by the project). This makes the most sense since there's no conflict and it will be easier for others to find them. However, if the project does maintain a presence on the Central Repository, then if there's a fork you have two choices: 1. Get the original project to upload the artifacts in their own groupId (unlikely since there's a reason it was a fork) 2. Upload them under your the forked project groupId (presumably one you own and appropriate for the fork)