For awareness,
I am looking at it, but will be a bit slow while at EclipseConverge and Devoxx. Looking at the problem it seems that the resolver should find a solution pretty easily but the presence of one of the versions of org.apache.httpcomponents.httpcore_4.4.4.v20161115-1643 (there are three versions of this bundle!!) is causing something to happen where the resolver discards the correct solution.
Tom
----- Original message -----
From: Andreas Sewe <andreas.sewe@xxxxxxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
To: equinox-dev@xxxxxxxxxxx
Cc:
Subject: Re: [equinox-dev] Uses constraint violation: -clean doesn't find solution even though it exists
Date: Mon, Mar 20, 2017 7:03 AM
Hi,
> Having only one exporter of a package is generally the best way to avoid
> choice :-)
I know. Sadly, that's not a (short term) solution to this particular
problem (see below).
> The import [4.2.1,4.4) seems very odd. Why the upper limit on 4.4? This
> seems to ignore semantic versioning. I would have expected [4.2,5).
I would have expected this as well, but am unsure whether the original
developers of Eclipse Aether felt the need to be conservative because of
a prior problem with Apache HttpComponents (non)adherence to semantic
versioning.
What's worse, the Aether project has been terminated [1] at Eclipse.
Newer versions of Aether are only available as non-OSGi bundles under
the name org.apache.maven.resolver [2] (but still with
org.eclipse.aether packages).
We can bring those to Orbit, of course, but that takes some time and
AFAIK the IP check deadline for Oxygen lies in the past already.
Also, we (rather than the Aether developers) are then responsible for
getting all the imports right. ;-)
> Similarly [4.3.3,) is too broad. I would have expected [4.3,5). These
> version ranges would appear to be hand written as Bnd would not make
> those choices.
The org.apache.httpcomponents.httpcore 4.3.3 bundle is handwritten. The
org.eclipse.aether.transport.http bundle uses the maven-bundle-plugin,
with the following instructions [3].
> org.eclipse.aether.transport.http needs to be fixed to widen the import
> range for org.apache.http.
I can try bringing it (and the other now-Apache Aether bundles) to
Orbit. At least we have bnd-based tooling available for this, but I
don't think this will be possible for Oxygen.
Best wishes,
Andreas
[1]
<https://projects.eclipse.org/projects/technology.aether/reviews/termination-review>
[2]
<http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.apache.maven.resolver%22>
[3]
<http://git.eclipse.org/c/aether/aether-core.git/tree/aether-transport-http/pom.xml?h=aether-1.0.1.v20141111#n120>
--
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
