My main question is ... is this required for Luna? (I assume not, that it shows up in "e4 incubator"? so could wait to SR1 if we find a safe, non-breaking change? Or Mars if breaking?)
Second, I've only barely read the details (they make my head spin) but wondering if it is reasonable for "resolver.problem" to require Java 8 AND javax.annotaion 1.0.0? That seems quite a mix of "old and new"? I assume this is an attempt to "be compatible" with older bundles that require javax.annotation 1.0? If it helps, and if you haven't already, you might want to read https://bugs.eclipse.org/bugs/show_bug.cgi?id=424909#c0 and what it points to, https://bugs.eclipse.org/bugs/show_bug.cgi?id=422981#c5 Now for some "wild ideas" to show my ignorance ... which helps occasionally :) ... I notice in Orbit, all our "javax.annotation" bundles follow the import what you export pattern .... that's good, such as Export-Package: javax.annotation;version="1.2.0", javax.annotation.security;version="1.2.0", javax.annotation.sql;version="1.2.0" Import-Package: javax.annotation;version="1.2.0", javax.annotation.security;version="1.2.0", javax.annotation.sql;version="1.2.0" BUT, in this case, I wonder if we should be so "restrictive" about what we import? Would the following be better? Export-Package: javax.annotation;version="1.2.0", javax.annotation.security;version="1.2.0", javax.annotation.sql;version="1.2.0" Import-Package: javax.annotation, javax.annotation.security, javax.annotation.sql I suppose that's about the same as "requiring system.bundle"? Just "mix in" with what ever in in running JRE? (Which, from https://bugs.eclipse.org/bugs/show_bug.cgi?id=422981#c5 sounds like it would work, in this case ... that is, high degree of similarity, except for "new" things? I'm just throwing this out as an idea ... only the experts could say if it makes sense. As for your suggestion b) guava does import javax.annotation;1.0.0 instead I'm assuming our Orbit guava version is what they (the "third party") provides (which is what we always strive for) so you might work with them, to find out if there's a reason they did it the way they did, if they'd be willing to change, etc. But I'm mostly asking ... this isn't blocking Luna, right? Thanks, From: Tom Schindl <tom.schi...@bestsolution.at> To: equinox-...@eclipse.org, E4 Project developer mailing list <e4-dev@eclipse.org>, orbit-...@eclipse.org, Date: 06/10/2014 04:32 PM Subject: [equinox-dev] Resolver Problem with guava and e4 (javax.annotation) Sent by: equinox-dev-boun...@eclipse.org Hi, [cross posting because different projects are involved in the problem] I've just discover a problem when one tries to use e4-DI and com.google.guava 15.0.0. The MANIFEST.MF is really simply: > Manifest-Version: 1.0 > Bundle-ManifestVersion: 2 > Bundle-Name: Problem > Bundle-SymbolicName: resolver.problem > Bundle-Version: 1.0.0.qualifier > Bundle-RequiredExecutionEnvironment: JavaSE-1.8 > Import-Package: javax.annotation;version="1.0.0" > Require-Bundle: com.google.guava;bundle-version="15.0.0" and when trying to resolve it one gets: > resolver.problem [196] > Bundle was not resolved because of a uses contraint violation. > org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to resolve resource resolver.problem [osgi.identity; osgi.identity="resolver.problem"; type="osgi.bundle"; version:Version="1.0.0.qualifier"] because it is exposed to package 'javax.annotation' from resources javax.annotation [osgi.identity; osgi.identity="javax.annotation"; type="osgi.bundle"; version:Version="1.2.0.v201401042248"] and org.eclipse.osgi [osgi.identity; osgi.identity="org.eclipse.osgi"; type="osgi.bundle"; version:Version="3.10.0.v20140528-2014"; singleton:="true"] via two dependency chains. > > Chain 1: > resolver.problem [osgi.identity; osgi.identity="resolver.problem"; type="osgi.bundle"; version:Version="1.0.0.qualifier"] > import: (&(osgi.wiring.package=javax.annotation)(version>=1.0.0)) > | > export: osgi.wiring.package: javax.annotation > javax.annotation [osgi.identity; osgi.identity="javax.annotation"; type="osgi.bundle"; version:Version="1.2.0.v201401042248"] > > Chain 2: > resolver.problem [osgi.identity; osgi.identity="resolver.problem"; type="osgi.bundle"; version:Version="1.0.0.qualifier"] > require: (&(osgi.wiring.bundle=com.google.guava)(bundle-version>=15.0.0)) > | > provide: osgi.wiring.bundle; bundle-version:Version="15.0.0.v201403281430"; osgi.wiring.bundle="com.google.guava" > com.google.guava [osgi.identity; osgi.identity="com.google.guava"; type="osgi.bundle"; version:Version="15.0.0.v201403281430"] > import: (osgi.wiring.package=javax.annotation) > | > export: osgi.wiring.package: javax.annotation > org.eclipse.osgi [osgi.identity; osgi.identity="org.eclipse.osgi"; type="osgi.bundle"; version:Version="3.10.0.v20140528-2014"; singleton:="true"] The reason is that guava optionally imports: Import-Package: javax.annotation;resolution:=optional,javax.inject;res olution:=optional,sun.misc;resolution:=optional So guava wires to the package from the JDK and presents classes in its API so I guess that's why the bundles who uses guava results in the resolution conflict. There are 2 possible solutions: a) because we now require JavaSE-6 in all our e4 code we could remove the need for explicit javax.annotation imports - this would break existing code but is maybe the correct solution in the long run? b) guava does import javax.annotation;1.0.0 instead Tom _______________________________________________ equinox-dev mailing list equinox-...@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________ e4-dev mailing list e4-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/e4-dev
