Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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.
Also related:


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:

    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?
    eclipse-pmc mailing list
    To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top