Having only one exporter of a package is generally the best way to avoid choice :-)
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). 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.
org.eclipse.aether.transport.http needs to be fixed to widen the import range for org.apache.http.
--
BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
hargrave@xxxxxxxxxx
----- Original message -----
From: Andreas Sewe <andreas.sewe@xxxxxxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
To: Equinox <equinox-dev@xxxxxxxxxxx>
Cc:
Subject: [equinox-dev] Uses constraint violation: -clean doesn't find solution even though it exists
Date: Fri, Mar 17, 2017 12:03 PM
Hi,
I am currently investigating a nasty uses conflict (Bug 513809 [1]) that
causes severe problems in several Oxygen M6 EPP packages (at least Java
and JEE) and I could really need some help from an OSGi expert.
First, the wiring problem in question *does* have a solution, but -clean
doesn't find it. Is this an Equinox bug or simply a known limitation,
given the NP completeness of bundle resolution?
Second, some of the Import-Packages' version ranges look either overly
specific [4.2.1,4.4) or overly broad [4.3.3,), so I wonder *if* this
problem could be prevented by fixing those Import-Packages (under the
assumption that all bundles in question adhere to semantic versioning).
Anyway, here's the uses conflict I was talking about:
> Chain 1:
> org.eclipse.aether.transport.http [osgi.identity; type="osgi.bundle"; version:Version="1.0.1.v20141111"; osgi.identity="org.eclipse.aether.transport.http"]
> import: (&(osgi.wiring.package=org.apache.http)(&(version>=4.2.1)(!(version>=4.4.0))))
> |
> export: osgi.wiring.package: org.apache.http
> org.apache.httpcomponents.httpcore [osgi.identity; type="osgi.bundle"; version:Version="4.3.3.v201411290715"; osgi.identity="org.apache.httpcomponents.httpcore"]
>
> Chain 2:
> org.eclipse.aether.transport.http [osgi.identity; type="osgi.bundle"; version:Version="1.0.1.v20141111"; osgi.identity="org.eclipse.aether.transport.http"]
> import: (&(osgi.wiring.package=org.apache.http.auth)(&(version>=4.2.1)(!(version>=4.4.0))))
> |
> export: osgi.wiring.package=org.apache.http.auth; uses:=org.apache.http.protocol
> org.apache.httpcomponents.httpclient [osgi.identity; type="osgi.bundle"; version:Version="4.3.6.v201511171540"; osgi.identity="org.apache.httpcomponents.httpclient"]
> import: (&(osgi.wiring.package=org.apache.http.protocol)(version>=4.3.3))
> |
> export: osgi.wiring.package: org.apache.http.protocol; uses:=org.apache.http
> export: osgi.wiring.package=org.apache.http
> org.apache.httpcomponents.httpcore [osgi.identity; type="osgi.bundle"; version:Version="4.4.6.v20170210-0925"; osgi.identity="org.apache.httpcomponents.httpcore"]
In my opinion, the above could be solved by wiring all packages imported
by bundle org.apache.httpcomponents.httpclient 4.3.6.v201511171540 to
the packages exported by bundle org.apache.httpcomponents.httpcore
4.3.3.v201411290715 (as is done in Neon.3), but apparently the presence
of a newer version of org.apache.httpcomponents.httpcore is too tempting
for Equinox.
Any insights on this issue are really appreciated.
Best wishes,
Andreas
[1] <https://bugs.eclipse.org/bugs/show_bug.cgi?id=513809#c0>
--
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
