[
https://issues.apache.org/jira/browse/FELIX-2918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021115#comment-13021115
]
Stuart McCulloch commented on FELIX-2918:
-----------------------------------------
Actually I mis-spoke about the multiple() case in Peaberry - it does in fact
create thin proxies around the individual elements, so there could potentially
be an issue with the ImportProxyClassLoader (although it does delegate to the
classloader of the type being proxied, so it should still find the same
dependent types). I think we really need a testcase to analyze this further
though. Note it doesn't have to be minimal, just as long as it's something I
can test locally (even binary bundles are ok) - feel free to email it directly
to me (mcculls) if you don't want to attach it to the issue.
> 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
