Re: [equinox-dev] Resolver Problem with guava and e4 (javax.annotation)

[David M Williams <david_williams@xxxxxxxxxx>]

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.schindl@xxxxxxxxxxxxxxx>
To:      
 equinox-dev@xxxxxxxxxxx,
E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>, orbit-dev@xxxxxxxxxxx,

Date:      
 06/10/2014 04:32 PM
Subject:    
   [equinox-dev]
Resolver Problem with guava and e4 (javax.annotation)
Sent by:    
   equinox-dev-bounces@xxxxxxxxxxx

---

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