Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse-pmc] Publishing to Maven Central - please comment

Dear PMC,

in 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

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

POM content: in 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
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.

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

Did I miss any relevant concern?


Back to the top