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

2017-03-20 Thread 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 Sent by: equinox-dev-boun...@eclipse.orgTo: equinox-dev@eclipse.orgCc:Subject: Re: [equinox-dev] Uses constraint violation: -clean doesn't find solution even though it existsDate: 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 particularproblem (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 originaldevelopers of Eclipse Aether felt the need to be conservative because ofa prior problem with Apache HttpComponents (non)adherence to semanticversioning.What's worse, the Aether project has been terminated [1] at Eclipse.Newer versions of Aether are only available as non-OSGi bundles underthe name org.apache.maven.resolver [2] (but still withorg.eclipse.aether packages).We can bring those to Orbit, of course, but that takes some time andAFAIK the IP check deadline for Oxygen lies in the past already.Also, we (rather than the Aether developers) are then responsible forgetting 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. Theorg.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) toOrbit. At least we have bnd-based tooling available for this, but Idon't think this will be possible for Oxygen.Best wishes,Andreas[1][2][3]--Codetrails GmbHThe knowledge transfer companyRobert-Bosch-Str. 7, 64293 DarmstadtPhone: +49-6151-276-7092Mobile: +49-170-811-3791http://www.codetrails.com/Managing Director: Dr. Marcel BruchHandelsregister: Darmstadt HRB 91940 
 
___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/equinox-dev
 

___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

2017-03-20 Thread 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]

[2]

[3]


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



signature.asc
Description: OpenPGP digital signature
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

2017-03-20 Thread 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 HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Andreas Sewe Sent by: equinox-dev-boun...@eclipse.orgTo: Equinox Cc:Subject: [equinox-dev] Uses constraint violation: -clean doesn't find solution even though it existsDate: Fri, Mar 17, 2017 12:03 PM 
Hi,I am currently investigating a nasty uses conflict (Bug 513809 [1]) thatcauses severe problems in several Oxygen M6 EPP packages (at least Javaand JEE) and I could really need some help from an OSGi expert.First, the wiring problem in question *does* have a solution, but -cleandoesn'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 overlyspecific [4.2.1,4.4) or overly broad [4.3.3,), so I wonder *if* thisproblem could be prevented by fixing those Import-Packages (under theassumption 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.v2014"; 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.v2014"; 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 importedby bundle org.apache.httpcomponents.httpclient 4.3.6.v201511171540 tothe packages exported by bundle org.apache.httpcomponents.httpcore4.3.3.v201411290715 (as is done in Neon.3), but apparently the presenceof a newer version of org.apache.httpcomponents.httpcore is too temptingfor Equinox.Any insights on this issue are really appreciated.Best wishes,Andreas[1] --Codetrails GmbHThe knowledge transfer companyRobert-Bosch-Str. 7, 64293 DarmstadtPhone: +49-6151-276-7092Mobile: +49-170-811-3791http://www.codetrails.com/Managing Director: Dr. Marcel BruchHandelsregister: Darmstadt HRB 91940 
 
___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/equinox-dev
 

___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev