Uses constraint violation: -clean doesn't find solution even though it exists

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Uses constraint violation: -clean doesn't find solution even though it exists

Andreas Sewe
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


_______________________________________________
equinox-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Uses constraint violation: -clean doesn't find solution even though it exists

BJ Hargrave
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
[hidden email]
 
 
----- Original message -----
From: Andreas Sewe <[hidden email]>
Sent by: [hidden email]
To: Equinox <[hidden email]>
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

 
_______________________________________________
equinox-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
 


_______________________________________________
equinox-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Reply | Threaded
Open this post in threaded view
|

Re: Uses constraint violation: -clean doesn't find solution even though it exists

Andreas Sewe
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


_______________________________________________
equinox-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Uses constraint violation: -clean doesn't find solution even though it exists

Thomas Watson
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 <[hidden email]>
Sent by: [hidden email]
To: [hidden email]
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

 
_______________________________________________
equinox-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
 


_______________________________________________
equinox-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev