[Bug 528797] Coordinate when & how artifacts are published to Maven Central
Bugzilla Link | 528797 |
Status | NEW |
Importance | P3 normal |
Reported | Dec 14, 2017 12:48 EDT |
Modified | Mar 21, 2020 06:24 EDT |
See also | 534936, 500769 |
Description
I suggest to coordinate the process of publishing to Maven Central in similar ways as the Simultaneous Release already does for publishing eclipse packages and p2 repositories.
This is not to start yet another discussion about which technology should be used (agreeing on one technology could be a second step, once / if we agree on the need for coordination and the desired process).
Claim: Eclipse artifacts are more and more widely consumed in Maven builds\
--------------------------------------------------------------------------Typically (as also some expressed in today's meeting), Eclipse developers tend to think that only a few leaf components produced at Eclipse.org are actually candidates for consumption via Maven (to mean: without tycho).
I'm, however, observing some motion that could imply that isolated solutions by individual projects are insufficient and could lead to confusion.
E.g., the Nov 2017 minutes of the AC [1] mention:
Jim: would like to mirror repo.* to Maven Central
which also entailed some disussion on the mailing list.
There was a lot of interest when we worked on publishing all artifacts of Platform, JDT and PDE to Maven Central (see [2] and linked bugs).
A lot of EMF- and Xtext-based software is consumed in plain maven builds.
I'm sure there are more examples.
With widespread adoption comes the need for coordination\
--------------------------------------------------------------------------If this a trend that not only I am seeing, then I am sure, that consumers will run into all kinds of difficulties finding all transitive dependencies in Maven builds.
Firstly, dependencies between Eclipse projects: In MANIFEST.MF, we simply express dependencies using BSN and a version range (hopefully adhering to semantic versioning). It is not trivial how to translate those dependencies to Maven, and if you don't own the other project, it may be impossible to guess.
-
even the simple G:A:V coordinates involve significant uncertainty:\
- what's the groupId (see bug 288644 - do projects know about it?)\
- should 4-part versions be kept? which delimiter?
how to identify release versions? should we publish snaptshots?\ - are version ranges a viable option in Maven land?
if so, should we help users in creating reproducible builds with exact
version dependencies (of all transitive dependencies)?\ - are parent poms used? which and how?
-
are orbit dependencies reliably translated back to their "original" G:A:V?
Nothing worse than different projects pulling in the same 3rd party lib
using different IDs!!
Secondly, even if a project knows the coordinates of another project it depends on, can it rely on a release schedule for required artifacts appearing on Maven Central at a specific point in time?
Thirdly, even disregarding dependencies between projects, creating proper Maven metadata involves a few choices, where guidance for projects joining the train would be useful. Aspects include: linking to git repo, listing developers and also: how to translate OSGi Fragments and their dependencies to Maven?
I hold that these issues are direct twins of the reasons for having a Simultaneous Release in the first place.
Some possible solutions\
--------------------------------------------------------------------------A full solution could be established by adding an opt-in flag to SimRel, whereby projects express whether or not they participate in coordinated publishing to Maven Central. For those that do, the aggregation could perform necessary checks to ensure that all dependencies can be fulfilled. From there, also the technical process could be unified as much as desired.
Once a project opts in, it will have to provide a few more details, minimally the groupId and basic metadata of the project.
At an intermediate level, instead of full integration with SimRel a working group of release engineers of participating projects could "manually" coordinate their dependencies and schedules.
Minimally, all projects that do publish to Maven Central should publish the what and how in some central or standardized way.
I could also think of making this a standard entry in the PMI's release records.
Obviously, the full solution would require to invest a bit of effort up-front but personally I'm convinced that this will pay off quickly, and once the process has become routine it will create huge benefits for consumers - once more demonstrating that Eclipse releases can be relied upon :)
[1] https://wiki.eclipse.org/Architecture_Council/Meetings/November_9_2017\ [2] https://wiki.eclipse.org/Platform-releng/Publish_To_Maven_Central