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
