[
https://issues.apache.org/jira/browse/FELIX-2918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020920#comment-13020920
]
Peter Kriens commented on FELIX-2918:
-------------------------------------
I think the problem is caused by improper dynamic loading in Guice and not bnd.
Why do you expect to see package b in the analysis of A? A has no reference to
package b whatsoever, look in the class file.
a.AS -> e.ES -> b.AD. Therefore A should import e but not more.
If you look at the class file for AS you will not find any reference of AD nor
AH because these are referenced by EW and ES. To make it more clear, I
simplified the example a bit:
A: package a;
public class A implements B {}
B: package b;
public interface B extends C {}
C: package c;
public interface C {}
It is clear here that A should not import C. It is likely that the Guice code
tries to load the interfaces through the same class loader but it must follow
the rules and use the loader of interface B to load interface C and not as it
seems to do now, the loader of class A.
If you can verify this, please close the bug otherwise please try to make a
minimal example and send it to me..
> Missing package in Import-Package causes NoClassDefFoundError at runtime
> ------------------------------------------------------------------------
>
> Key: FELIX-2918
> URL: https://issues.apache.org/jira/browse/FELIX-2918
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
> Affects Versions: maven-bundle-plugin-2.3.4
> Environment: OSX Snow Leopard, Maven3, Java6, Guice/Peaberry
> Reporter: Yuri
> Priority: Minor
>
> I have an issue where I get a NoClassDefFoundError while starting my
> multi-project bundles. This exception is thrown while Peaberry is creating an
> proxy for a multiple() import. Aside from the Peaberry specifics, the
> multiple() import is loading the service interface, it's implementation and
> dependencies until it hits this error. After taking a closer look and
> comparing the bundle giving me grief to another similar (wrt dependencies)
> one that was working fine, I noticed two differences in the Manifest: a
> missing package in the Import-Package and the same package missing from the
> uses directive in the Export-Package. Basically, maven-bundle-plugin was not
> "seeing" the missing package when auto generating the manifest.
> The scenario, in more detail, is as follows.
> Bundle A (the one with the missing package in the manifest) imports packages
> from bundle E:
> BUNDLE A (package a):
> --------
> interface a.AS extends e.ES<a.AS,a.AW>{}
> interface a.AW extends e.EW<a.AS,a.AW>{}
> BUNDLE E (packages e and b):
> --------
> interface e.EW<S extends e.ES<S,W>, W extends e.EW<S,W>> extends b.AD, b.AH{}
> interface b.AD{} // THIS IS THE NoClassDefFoundError CLASS
> interface b.AH{}
> I then ran my mvn3 build with maven-bundle-plugin v2.3.4 and attached a
> debugger to it. I then stopped in the aQute.lib.osgi.Analyzer line
> 1684 (t.addAll(clazz.getReferred());) for class a.AS. I was expecting
> to see packages a (for a.AS and the two generic parameters a.AS and
> a.AW, which happens to be in the same package), e (for e.ES interface,
> and the two generic parameters a.ES and e.EW, which happens to be in
> the same package) and b (b.AD and b.AH). However, I didn't see the
> package b there.
> So it seems that BND is not analyzing dependencies of dependencies and the
> reason my other module worked was because there was an unrelated, direct
> dependency to package b somewhere else, forcing the package to be added to
> the Manifest.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
