[
https://issues.apache.org/jira/browse/FELIX-2918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021081#comment-13021081
]
Yuri commented on FELIX-2918:
-----------------------------
Peter, the behavior you describe above makes sense and I guess the problem then
is in either Guice or Peaberry. As soon as we confirm that this is a Guice or
Peaberry issue I will close the bug.
Stuart, I am currently using maven-bundle-plugin v2.3.4, Guice v3.0 and
Peaberry v1.2-SNAPSHOT. And the issue happened with a multiple() import. So is
it likely that the problem is with the non-proxied Iterable implementation? Now
that there is some clarity on the issue, I will take the time to create a
minimal test. How much effort do you envision for having a proxied Iterable?
> 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