[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] Maven snapshot repository available ?
- From: Stephan Herrmann <stephan.herrmann@xxxxxxxxx>
- Date: Tue, 11 Apr 2017 16:05:41 +0200
- Delivered-to: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
On 11.04.2017 15:03, Andreas Sewe wrote:
...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.
Good reasoning, but I did not feel entitled to effectively *change*
the meta data of all of the Eclipse project in the official upload.
(And no-one spoke up when I announce my strategy on eclipse-dev :p)
Semantic versioning is a key factor in the reusability of Eclipse
components, where the consumer building an application decides the
exact combination of versions, not the library provider.
In fact, my company use of mavenized artifacts heavily relies on the
ability to combine artifacts in our specific selection of versions,
in particular to avoid a dependency on Java 8 (so some artifacts are
nailed to Luna), while consuming latest from other components.
I recently learned, that Maven indeed has an equivalent of what we
call the "target platform": create a pom with only a huge section
of dependencyManagement and then let your main pom depend on that
'target platform' with scope "import".
Keeping original version ranges and using this huge dependencyManagement
is the best translation into Maven-land that I could come up.
If for the future artifacts published to Maven should be significantly
different from what we publish to our p2 consumers, then this would
have to be driven by someone else, I'm afraid. Likely the Eclipse PMC
should first define the strategy in that case.