Thank you, I did see that and do use the maven bundle plugin, however it was just too much magic, especially for the toy examples that I was playing around with. Made more sense to try and actually create a manifest by hand, just from the point of view of understanding.
Having crossed that barrier, definitely do agree bnd is far better than me trying to create manifest files by hand. Thanks Bhaskar On Mon, Apr 21, 2008 at 6:40 AM, Mirko Jahn <[EMAIL PROTECTED]> wrote: > On Mon, Apr 21, 2008 at 12:01 PM, Stuart McCulloch > <[EMAIL PROTECTED]> wrote: > > On 18/04/2008, Bhaskar Maddala <[EMAIL PROTECTED]> wrote: > > > > > Awesome, Thank you, I probably should have cheated and asked sooner ;) > > > > just to wrap up this thread, you can use the Bnd tool to create bundles: > > > > http://aqute.biz/Code/Bnd > > > > and it will add the "uses" constraints for you by analyzing the bytecode. > > ( which is much, much easier than trying to calculate this manually :) > short add-on: > When using plug-in projects in Eclipse, the "Calculate Uses"-button in > the Manifest editor (in the runtime tab) offers you the same > convenience. > > > > > > > HTH > > > > > > > > > -Bhaskar > > > > > > On Fri, Apr 18, 2008 at 8:47 AM, Angelo van der Sijpt > > > > > > <[EMAIL PROTECTED]> wrote: > > > > > > > On 18 Apr 2008, at 14:23, Bhaskar Maddala wrote: > > > > > > > > > > > > > > > > > > However the uses directive in the absence of versions is still a bit > > > > > of a black hole. Going back to the original example > > > > > > > > > > A: Export-Package : foo > > > > > D: Export-Package : foo > > > > > C : Import-Package: foo, bar > > > > > B: Import-Package: foo > > > > > Export-Package: bar; uses:="foo" > > > > > > > > > > Is the choice of 'foo' in the 'absence' of the uses directive left to > > > > > the implementation? > > > > > > > > > > > > > In some sense, the foo which C and B get wired to are up to the > > > > implementation. However, section 3.7 of the spec does give some rules > > for > > > > this: > > > > - A resolved exporter must be preferred over an unresolved exporter. > > > > - An exporter with a higher version is preferred over an exporter with > > a > > > > lower version. > > > > - An exporter with a lower bundle ID is preferred over a bundle with a > > > > higher ID. > > > > > > > > If we apply this to our scenario (leaving out the uses constraint), > > this > > > > will probably go right, even in different installation orders: one of A > > or D > > > > will be resolved first, so both C and B will be wired to the same > > bundle. > > > > However, with a little creativity, we can come up with an installation > > order > > > > in which C and B will be wired to different versions of foo. For > > example: > > > > install D > > > > install and start (or at least resolve) A > > > > install and resolve B (this will now get wired to A, since that is a > > > > resolved exporter) > > > > resolve D > > > > install and resolve C (this will now get wired to D, since that has a > > lower > > > > bundle ID) > > > > > > > > Note that the uses constraints states something like "If you want to > > use > > > > stuff from this package bar I export, make sure you use the same foo as > > I > > > > do". > > > > > > > > > > > > > > > > > Which might explain why I would not get any ClassCastException as the > > > > > implementation I tried (Knopflerfish) might have been picking the > > > > > correct foo class, I will post a message there too. > > > > > > > > > > > > > True, I don't believe this scenario can really go wrong when deploying > > all > > > > bundles at once. When you leave out the uses constraint, it still goes > > right > > > > 'by accident'. > > > > > > > > Angelo > > > > > > > > > > > > ----------------------------- > > > > Angelo van der Sijpt > > > > Software Engineer iQ Products > > > > ----------------------------- > > > > +31-6-23218231 > > > > [EMAIL PROTECTED] > > > > www.luminis.nl > > > > K.v.k. Centraal Gelderland: 09 16 28 93 > > > > ----------------------------- > > > > > > > > > > > > > > > > _______________________________________________ > > > > OSGi Developer Mail List > > > > osgi-dev@mail.osgi.org > > > > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > > > > _______________________________________________ > > > OSGi Developer Mail List > > > osgi-dev@mail.osgi.org > > > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > > > > > > > > -- > > Cheers, Stuart > > _______________________________________________ > > OSGi Developer Mail List > > osgi-dev@mail.osgi.org > > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > > > -- > Mirko Jahn > Heidelberger Str. 51 > 69126 Heidelberg > Germany > > Fon: +49 [0] 6221 - 431 28 58 > Mobile: +49 [0] 173 211 41 94 > E-Mail: [EMAIL PROTECTED] > Web: http://www.mjahn.net > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
