Hi Stephan., > Let me directly add some words of caution:
all good advice... > When pushing Eclipse artifacts to Maven Central we convert > OSGi 4 part versions to 3 part versions as suitable for a Maven Release. > > When anybody starts to publish snapshots they should be very > careful in testing that snapshots don't interfere with builds > requesting a release version. Example: [4.6.0,4.7.0) should > select any of 4.6.1, 4.6.2 ... but *not* 4.7.0. > As soon as a snapshot exists, e.g., as 4.7.0.v2017040112000 > then this version would be considered (by some maven versions) > as < 4.7.0 and thus be picked via the above version range. > Client builds using Maven may not customarily use such version > ranges, but dependencies among Eclipse artifacts do make use > of semantic versioning and thus could be wired in incompatible > ways. ...but why does publishing to central use version ranges in Maven dependencies on the first place? I get that these are a more truthful translation of the original OSGi manifests *but* AFAIK they not only suffer from the above problem but also make you build irreproducible; as Maven's "target platform" is "whatever is in Maven Central" at the moment, what a version range resolves to may change over time. IIRC, using version ranges are considered to be a bad practice by the Maven developers themselves for the latter reason. Best wishes, Andreas -- Codetrails GmbH The knowledge transfer company Robert-Bosch-Str. 7, 64293 Darmstadt Phone: +49-6151-276-7092 Mobile: +49-170-811-3791 http://www.codetrails.com/ Managing Director: Dr. Marcel Bruch Handelsregister: Darmstadt HRB 91940
signature.asc
Description: OpenPGP digital signature
_______________________________________________ equinox-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
