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, which 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 we will check that the groupId is appropriate for the project. Typically this means the groupId should match the java package name of your code, and that your project website or source control is located in a matching domain.
Look at More information about package names.
- www.springframework.org -> org.springframework
- oness.sf.net -> net.sf.oness
- groupId will identify your project uniquely across all projects, so we need to enforce a naming schema. 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. eg. org.apache.maven, org.apache.commons
A good way to determine the granularity of the groupId is to use the project structure. That is, if the current project is a multiple module project, it should append a new identifier to the parent's groupId.
eg. org.apache.maven, org.apache.maven.plugins, org.apache.maven.reporting
- artifactId is the name of the jar without version. If you created it then you can choose whatever name you want with lowercase letters and no strange symbols. If it's a third party jar you have to take the name of the jar as it's distributed.eg. maven, commons-math
- version if you distribute it then you can choose any typical version with numbers and dots (1.0, 1.1, 1.0.1, ...). Don't use dates as they are usually associated with SNAPSHOT (nightly) builds. If it's a third party artifact, you have to use their version number whatever it is, and as strange as it can look.eg. 2.0, 2.0.1, 1.3.1
We encourage (require) people to use a groupId they control by project or domain to name their artifacts. We have to be careful though how to apply this rule when people are trying to upload artifacts they don't control. The first inclination is for people to rename their artifacts to be under a groupId they do control. This is bad because 1) other people who would like to use these artifacts won't find them buried in your groupId and 2) classpath conflicts if the same artifact is uploaded under another groupId.
The theory behind how we will handle these cases derives from the following:
- Responsibility earns Authority. that when I define a groupId and start producing my 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.
- Authority is earned by responsibility (meritocracy). If I'm not representing my artifacts on Central, and someone else is willing to do so responsibly, then they effectively inherit that authority.
- Conflicts or future efforts will always favor the project. (ie if they later decide 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 Central then the process should be:
A1) try to get/assist them in providing artifacts themselves.
A2) if they don't, then we'll 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 Central, then if there's a fork you have two choices:
B1) get the original project to upload the artifacts in their own groupId (unlikely since there's a reason it was a fork)
B2) upload them under your the forked project groupId (presumably one you own and appropriate for the fork)