I don't think anything has changed in the resolver to cause this. If you run with -clean then the problem is 'fixed'. But that is really just by luck because of the policy by the OSGi specification to prefer pre-resolved exporters to unresolved ones when finding possible candidate exporters. Since the system bundle (framework) is always resolved when you do a -clean it causes the com.google.guava bundle to wire to the javax.annotation package from the system bundle because the javax.annotation orbit bundle has not been resolved yet.
The org.eclipse.fx.ide.cs bundle uses require-bundle on the org.eclipse.osgi (system bundle) that always wires it to the javax.annotation package from the VM. One way to give the resolver more 'freedom' would be to have the org.eclipse.fx.ide.cs bundle use Import-Package for javax.annotation. That way the resolver would detect the conflict and be able to swap the provider of the javax.annotation to match the one being used by the guava bundle. One of the evils of using Require-Bundle, it causes brittle relationships that cannot be substituted easily at runtime. There should be very few valid reasons to requiring the system.bundle (org.eclipse.osgi). Tom From: Stuart McCulloch <mccu...@gmail.com> To: Orbit Developer discussion <orbit-...@eclipse.org> Cc: Equinox development mailing list <equinox-dev@eclipse.org>, E4 Project developer mailing list <e4-...@eclipse.org> Date: 11/05/2014 06:33 AM Subject: Re: [equinox-dev] [orbit-dev] [e4-dev] Resolver Problem with guava and 4 javax.annotation) Sent by: equinox-dev-boun...@eclipse.org On Wednesday, 5 November 2014 at 11:34, Tom Schindl wrote: Hi, With Mars (whether this is a regression in the Equinox-Resolver) needs to be discussed but I'd really like us to start a discussion if we can get rid of the javax.annotation bundle itself. For the reference if I install e(fx)clipse tooling into Mars M3 I get: osgi> diag 317 org.eclipse.fx.ide.css [317] Bundle was not resolved because of a uses contraint violation. org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to resolve resource org.eclipse.fx.ide.css [osgi.identity; osgi.identity="org.eclipse.fx.ide.css"; type="osgi.bundle"; version:Version="1.1.0.201411050807"; singleton:="true"] because it is exposed to package 'javax.annotation' from resources org.eclipse.osgi [osgi.identity; osgi.identity="org.eclipse.osgi"; type="osgi.bundle"; version:Version="3.10.100.v20141020-1414"; singleton:="true"] and javax.annotation [osgi.identity; osgi.identity="javax.annotation"; type="osgi.bundle"; version:Version="1.2.0.v201401042248"] via two dependency chains. Chain 1: org.eclipse.fx.ide.css [osgi.identity; osgi.identity="org.eclipse.fx.ide.css"; type="osgi.bundle"; version:Version="1.1.0.201411050807"; singleton:="true"] require: (&(osgi.wiring.bundle=org.eclipse.osgi)(bundle-version>=3.7.0)) | provide: osgi.wiring.bundle: [org.eclipse.osgi, system.bundle] org.eclipse.osgi [osgi.identity; osgi.identity="org.eclipse.osgi"; type="osgi.bundle"; version:Version="3.10.100.v20141020-1414"; singleton:="true"] Chain 2: org.eclipse.fx.ide.css [osgi.identity; osgi.identity="org.eclipse.fx.ide.css"; type="osgi.bundle"; version:Version="1.1.0.201411050807"; singleton:="true"] require: (&(osgi.wiring.bundle=org.eclipse.xtext)(bundle-version>=2.0.0)) | provide: osgi.wiring.bundle; bundle-version:Version="2.8.0.v201409300608"; osgi.wiring.bundle="org.eclipse.xtext"; singleton:="true" 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 javax.annotation [osgi.identity; osgi.identity="javax.annotation"; type="osgi.bundle"; version:Version="1.2.0.v201401042248"] Eclipse 4 IDE and Eclipse 4 Application Platform already has Java6 as a prerequisit so technically we don't need javax.annotation because it is provided by the JRE. Does anything in E4 use @javax.annotation.Priority which was added in 1.2? If so then the bundle is still needed because Java6 only includes version 1.0 of the spec. The problem is that all client bundles who use the e4 DI container do versioned imports whereas e.g. external bundles like guava do a version less import, so if we'd modify our own bundles to use the JRE version they would all fail. Do we need a boarder forum like cross-platform? Tom On 15.06.14 06:55, David M Williams wrote: I don't know if this problem was solved ... or worked around .... but didn't want the issue to get lost, so I opened a bug in Orbit, https://bugs.eclipse.org/bugs/show_bug.cgi?id=437470 to make sure the issue isn't "lost" (thought not sure it's a true "Orbit Bug" ... seemed as good a place as any). Thanks, From: David M Williams/Raleigh/IBM@IBMUS To: E4 Project developer mailing list <e4-...@eclipse.org>, Cc: orbit-...@eclipse.org, Equinox development mailing list <equinox-dev@eclipse.org> Date: 06/11/2014 02:55 AM Subject: Re: [equinox-dev] [e4-dev] Resolver Problem with guava and e4 (javax.annotation) Sent by: equinox-dev-boun...@eclipse.org ------------------------------------------------------------------------ I don't think so because from their point of view they are requireing JavaSE-1.6 and so they can wire to javax.annotation without packages. They could remove the javax.annotation import completely because they anyways require JavaSE-1.6 Well, not quite. javax.annotation 1.0.0 has a BREE of 1.5 (but is "native" to only 1.6, according to_https://bugs.eclipse.org/bugs/show_bug.cgi?id=422981#c5_ ) javax.annotation 1.1.0 has a BREE of 1.5 (but is "native" to only 1.7, according to '') javax.annotation 1.2.0 has a BREE of 1.6 (but is "native" to only 1.8, according to '' -- I think -- assuming it "made it in", but I do not know for sure) The idea being that projects could use annotations, as the specs came out, even on an "older" VM, rather than have to wait for the JRE that first contained it. _______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ orbit-dev mailing list orbit-...@eclipse.org https://dev.eclipse.org/mailman/listinfo/orbit-dev -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck _______________________________________________ orbit-dev mailing list orbit-...@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/orbit-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
_______________________________________________ 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