Re: [equinox-dev] [orbit-dev] [e4-dev] Resolver Problem with guava and 4

[Thomas Watson <tjwatson@xxxxxxxxxx>]

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 <mcculls@xxxxxxxxx>
To:      
 Orbit Developer discussion
<orbit-dev@xxxxxxxxxxx>
Cc:      
 Equinox development
mailing list <equinox-dev@xxxxxxxxxxx>, E4 Project developer mailing
list <e4-dev@xxxxxxxxxxx>
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-bounces@xxxxxxxxxxx

---

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-dev@xxxxxxxxxxx>,
Cc: orbit-dev@xxxxxxxxxxx,
Equinox development mailing list
<equinox-dev@xxxxxxxxxxx>
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-bounces@xxxxxxxxxxx
------------------------------------------------------------------------



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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev



_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
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-dev@xxxxxxxxxxx
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@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev