You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Yuri (JIRA)" <ji...@apache.org> on 2011/06/03 21:44:47 UTC

[jira] [Commented] (FELIX-2918) Missing package in Import-Package causes NoClassDefFoundError at runtime

    [ https://issues.apache.org/jira/browse/FELIX-2918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13043995#comment-13043995 ] 

Yuri commented on FELIX-2918:
-----------------------------

Sorry it took so long, but I finally got some time to put together a simplified test case. You can find it here: https://github.com/ydewit/FELIX-2918

It turns out that the issue is with erased types. Since maven-bundle-plugin is generating the dependencies from compiled bytecode, all erased dependencies are not visible. Of course, this is not an issue when using the MANIFEST.MF at runtime with a OSGi framework and most likely the expected behavior since those erased dependencies are never used there. However, this was a source of a bit of pain because I was trying to use the MANIFEST.MF at development-time in Eclipse PDE. I was trying to use maven-bundle-plugin to generate a MANIFEST.MF that would include all source code package dependencies so it could be used seamlessly by Eclipse PDE (in the same way that mvn eclipse:eclipse solves this problem for non-osgi apps and JDT).

So it's not really an issue with maven-bundle-plugin or BND, but a question of how to integrate Maven and Eclipse when developing OSGi apps. There are some options here (Tycho, Buckminster, PDE Build, etc), but I like the maven-centric approach and just wish I could reuse the tooling around Eclipse PDE without having to manually duplicate metadata.

> 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