Re: [eclipse-pmc] Publishing to Maven Central - please comment

[Lars Vogel <lars.vogel@xxxxxxxxxxx>]

Stephan, thanks for this work.

The next  PMC call is on 13. Dec. and I suggest we discuss it there.

Best regards, Lars

On Thu, Dec 8, 2016 at 3:33 PM, Stephan Herrmann
<stephan.herrmann@xxxxxxxxx> wrote:
> Dear PMC,
>
> 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.
>
>
> ASKING:
> =======
>
> 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?
>
>
> PROPOSING:
> ==========
>
> 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#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
> 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
>
>
> Did I miss any relevant concern?
>
> thanks,
> Stephan
> _______________________________________________
> eclipse-pmc mailing list
> eclipse-pmc@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/eclipse-pmc



-- 
Eclipse Platform UI and e4 project co-lead
CEO vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (040) 5247 6322, Email: lars.vogel@xxxxxxxxxxx, Web: http://www.vogella.com