As a final note, this seems definitely a bug. It seems that bnd should be going deeper in the dependency tree.
For now, as a work around, I added a dummy dependency to b.AH from Bundle A and I am moving ahead. On Thu, Apr 14, 2011 at 6:52 PM, Yuri de Wit <[email protected]> wrote: > And the reason that the other two bundles I have work is because the > have another direct dependency on a.AD and a.AH. > > So, if I have bundle A containing: > - interface a.AS extends e.ES<a.AS,a.AW>{} > - interface a.AW... > > and a bundle E containing: > - interface e.ES<S extends e.ES<S,W>, W extends e.EW<S,W>> extends b.AD, > b.AH{} > - interface e.EW.. > - interface b.AD{} > - interface b.AH{} > > I would expect that the bundle A manifest would contain an explicit > Import-Package to package b, but that is not the case. > > On Thu, Apr 14, 2011 at 6:26 PM, Yuri de Wit <[email protected]> wrote: >> I 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. >> >> I am not sure if the code is supposed to analyze a.ES a bit later and >> then uncover b.AD and b.AH, but I did verify that after analyze is >> done I do not see package b referred. >> >> Here is the makeup for the a.AS class being analyzed by bnd: >> >> interface a.AS extends e.ES<a.AS,a.AW>{} >> interface e.ES<S extends e.ES<S,W>, W extends e.EW<S,W>> extends b.AD, b.AH{} >> >> >> On Thu, Apr 14, 2011 at 11:55 AM, Yuri de Wit <[email protected]> wrote: >>> Peter, >>> >>> This is picture of the dependencies here: >>> >>> This is a more detailed picture: >>> BUNDLE A (package a): >>> -------- >>> BundleModule { >>> bindService(a.AS).export(); >>> bindService(a.AW).multiple(); // THIS IS WHEN THE EXCEPTION IS THROWN >>> bind(a.AS).to(a.ASImpl); >>> } >>> >>> class a.ASImpl extends e.ESImpl<a.AS,a.AW> implements a.AS { >>> ASImpl(EB, Iterable<a.AW>) >>> } >>> >>> 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.ES<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{} >>> >>> Considering that I have an additional bundle with the same >>> dependencies (and more) and that bundle has the "b" package included >>> in the Manifest, i.e. it works, could it be that the >>> maven-bundle-plugin is not "seeing" b.AD through the >>> generics/inheritance when building the bundle manifest and that it >>> works here due to another dependency to b.AD? >>> >>> On Thu, Apr 14, 2011 at 11:10 AM, Yuri de Wit <[email protected]> wrote: >>>> Indeed. I used the latest 2.3.5-SNAPSHOT and got the same results. >>>> >>>> I am using Peaberry/Guice to import a service from the base module and >>>> the ClassDefNotFoundError is thrown when importing multiple() in >>>> Peaberry's BundleModule. However, I checked the Manifest on both the >>>> bundle that works and the one that doesnt and see the difference in >>>> the "uses" directive exactly in the package that contains the missing >>>> class def. The two bundles extend the base bundle in the exact same >>>> way and the only thing special here is the 3 level deep inheritance >>>> and multiple interface extension with Generics, but they would then be >>>> special for both bundles: not sure why would one work and one fail. >>>> >>>> If I build the bundle with the missing package in the uses directive >>>> from the bundle project, as opposed to the parent project, I get the >>>> exact same result (I was wondering if the reactor with all the other >>>> projects could be causing a problem here). >>>> >>>> thanks, >>>> >>>> On Thu, Apr 14, 2011 at 8:34 AM, Peter Kriens <[email protected]> >>>> wrote: >>>>> If you can send the culprit to me then I will have a look. >>>>> >>>>> It sounds a bit odd, a missing uses directive should not end up in Class >>>>> Def Not Found error, worst case you could get a class cast exception. >>>>> Uses are only important for systems that have multiple versions of the >>>>> same package. >>>>> >>>>> It is not very likely that 1.43.0 is improving such a situation, no >>>>> changes have been made in this area. >>>>> >>>>> Kind regards, >>>>> >>>>> Peter Kriens >>>>> >>>>> On 14 apr 2011, at 08:55, Yuri de Wit wrote: >>>>> >>>>>> I noticed that the current 2.3.4 maven-bundle-plugin has a dependency >>>>>> on an older version of bndlib 1.15.0. Is there a snapshot somewhere >>>>>> with the latest 1.43.0? Where are the sources for the >>>>>> maven-bundle-plugin? >>>>>> >>>>>> The main reason I am interested in this is that I am having a strange >>>>>> issue where a "uses"directive is not being generated in the >>>>>> Import-Package/Export-Package for a specific package and I end up >>>>>> getting a NoClassDefFoundError when activating the module in felix. I >>>>>> have X and Y modules that depend on A module. The A module has an >>>>>> interface A that extends another interface b.B . The X interface in >>>>>> module X extends A and so does the Y interface in the module X. For >>>>>> some strange reason the X module has the uses=b, but the module Y >>>>>> doenst. >>>>>> >>>>>> I hacked the Manifest to include the missing package in the uses >>>>>> directive and it seems to have worked. So the question is why would >>>>>> maven-bundle-plugin not generate the b package in the uses directive >>>>>> for the Y module? >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >>> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
