Hi,
On Mon, Feb 27, 2012 at 4:45 PM, David G. <[email protected]> wrote: > Quick question about including/exposing dependencies for bundles running > under felix. > > As I understand it, there are predominantly 2 ways of exposing 3rd party libs > for use in our bundle: > > 1) Include the 3rd party jar files in the bundle's /lib folder - which > exposes all packages of the jar(s) to the code in the bundle. Just to add to what Richard pointed out, there is no need to export these external libs. > 2) Package the 3rd party jar/jars as an OSGi bundle, exporting the requisite > packages in the bnd by way of the manifest. > > I seems like the first strategy encourages potential for future conflicts (if > another bundle exports the same packages) but reduces the dependencies for > the bundle, since its self-contained. Here I agree with Richard, I do not see how this causes future conflicts. > The second strategy allows for reusability of code (all bundles that need 3rd > party library X can get the dependencies for the same bundle) however this > adds extra dependencies to the bundle deployment lifecycle (you may have > ensure that when Bundle A is deployed, there is process in place to deploy > 3rd party bundles X, Y and Z). > > - Thoughts around when to use one over the other? In a perfect OSGi world, the later approach is best, unluckily for us, we are not in that world. Here is where my experience differs from the experience Richard had. We found that if we always aim for the later approach we see two issues. (1) We go into a bundle-boom effect where we end up with many bundles and it is very hard to know what depends on what without a very high diligence and being sure that we do not have superfluous bundles takes a lot of time, and (2) if we have to work with legacy libraries that expect a single class loader that has it all, then the former approach makes everybody's life a lot easier. > - Are there any other dangers to using either method I didn't outline above? Here I agree with Richard, both ways work well, but there is no "one size fits all" approach. You can mix and match both approaches as needed. > - Any other options? When we go for the later approach, we try to keep everything into two types of bundles. (1) Bundles that just expose the interface to a service, and (2) bundles that export as few packages as possible and all the services definitions are declared thru DS (and, if possible, we export no package and only import the definition from the services we want to expose) Just to be clear, we do know that this approach does use more memory, does not allow for class loader short circuits and the class loader has to work more (once). Regards, Lucas > > Thanks > > > -- > David Gonzalez > Sent with Sparrow (http://www.sparrowmailapp.com/?sig) > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
