[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] Uses constraint violation: -clean doesn't find solution even though it exists
- From: "Thomas Watson" <tjwatson@xxxxxxxxxx>
- Date: Mon, 20 Mar 2017 15:32:28 +0000
- Delivered-to: firstname.lastname@example.org
- Importance: Normal
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.
----- Original message -----
From: Andreas Sewe <andreas.sewe@xxxxxxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
Subject: Re: [equinox-dev] Uses constraint violation: -clean doesn't find solution even though it exists
Date: Mon, Mar 20, 2017 7:03 AM
> 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
What's worse, the Aether project has been terminated  at Eclipse.
Newer versions of Aether are only available as non-OSGi bundles under
the name org.apache.maven.resolver  (but still with
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 .
> 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.
The knowledge transfer company
Robert-Bosch-Str. 7, 64293 Darmstadt
Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940