Re: [eclipse-pmc] Publishing to Maven Central - please comment
For some history on the GroupID discussion, see also here (and related comments):
It would be great if we could close that bug as a result of this discussion.
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
direct +43.662.457915.85 fax +43.662.457915.6
On 08/12/16 15:33, "eclipse-pmc-bounces@xxxxxxxxxxx on behalf of Stephan Herrmann" <eclipse-pmc-bounces@xxxxxxxxxxx on behalf of stephan.herrmann@xxxxxxxxx> wrote:
in https://bugs.eclipse.org/484004 I'm preparing for publishing
all relevant artifacts of the Eclipse Project to Maven Central.
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
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#c48 I 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
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.
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
Did I miss any relevant concern?
eclipse-pmc mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit