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.
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).
Stuart McCulloch <mcculls@xxxxxxxxx>
Orbit Developer discussion
mailing list <equinox-dev@xxxxxxxxxxx>, E4 Project developer mailing
11/05/2014 06:33 AM
[orbit-dev] [e4-dev] Resolver Problem with guava and 4 javax.annotation)
On Wednesday, 5 November 2014 at 11:34,
Tom Schindl wrote:
With Mars (whether this is a regression in the Equinox-Resolver)
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
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;
because it is exposed to package 'javax.annotation' from resources org.eclipse.osgi
[osgi.identity; osgi.identity="org.eclipse.osgi"; type="osgi.bundle";
and javax.annotation [osgi.identity; osgi.identity="javax.annotation";
via two dependency chains.
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?
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
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).
I don't think so because from their point of view they
JavaSE-1.6 and so they can wire to javax.annotation without
They could remove the javax.annotation import completely
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,
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)