We discussed this today in our PMC call
with the following outcome:
- We use the following 3-part group
ids 'org.eclipse.platform', 'org.eclipse.jdt' and 'org.eclipse.pde'. - We use 3-part versions without appending
the qualifier. - We start publishing with Neon Update
2 for now.
Stephan Herrmann <stephan.herrmann@xxxxxxxxx> To:
08.12.2016 15:33 Subject:
Publishing to Maven Central - please comment Sent by:
I have reached a state where a few things should be decided / approved.
What groupId should we use for the maven artifacts produced from our bundles - 3-part or 2-part?
- Existing poms in git use 3-part groupIds like "org.eclipse.jdt"
- An organizational downside of 3-part groupIds is that we'd have to create and use 26 different accounts on OSSRH.
- We could instead use groupId "org.eclipse" for all artifacts produced by the Eclipse Project.
- In Maven-land, about every possible strategy for groupIds is used for at least one artifact, so whatever we decide should be fine from a Maven p.o.v.
- Changing from 3-part (in git) to 2-part would break clients that might already be consuming some of these artifacts with 3-part groupId (whichever way they obtained those artifacts).
- Breaking the "tradition" of 3-part groupId could also be announced as start of a new "era": anything with 2-part groupId
is really officially published by Eclipse.org
I can live with either option. Releng / infra would have to work harder with 26 distinct groups. Since I see no hard reason against, I'm leaning towards 2-part group "org.eclipse".
May I kindly ask for a decision on this question?
Versioning: I'm confident that in Maven-land all our release artifacts should be identified by 3-part versions (i.e., 3.12.2, rather than 3.12.2.v20161117-1814). This is done because in Maven 4-part versions cannot be parsed. We could translate into 3-part-dash-qualifier (3.12.2-v20161117-1814 - mind the dash), but this would signal to Maven that ours' are SNAPSHOT builds, not release, which would be wrong. Ultimately, 3.12.2 will be regarded as newer than any longer form, so by publishing artifacts with 3-part versions we override any other artifacts that may have been published by volunteers outside Eclipse.org.
POM content: in https://bugs.eclipse.org/484004#c48I started to collect what pieces of information should be put into the poms used for publication. TLDR: poms will likely be crafted starting from the output of the CBI aggregator, ignoring much stuff from poms in git (which is irrelevant for Maven-based consumers).
It has been asked whether publishing to Maven Central will be done retroactively for older releases. For the time being I propose to do this for Neon.2 and all future releases. (Neon.2 also gives us the chance to improve with Neon.3, should anything be amiss). We can defer decision re older releases until we have experience the the current.
Please approve or comment in the bug.
RESOLVED: ========= All required 3rd party dependencies have been identified and remapped to GAV as available already from Maven Central. If s.o. wants to double check the list is in https://bugs.eclipse.org/484004#c47