On 2/27/12 14:45 , David G. 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.
Essentially, but there's no such think as a bundle's "/lib" folder, you
just simply embed the JARs into the bundle JAR file and then mention
them on the Bundle-ClassPath header (along with "." if you still need
access to the rest of the bundle's content directly).
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.
If the internal third-party JARs are only used internally by the bundle
and are not exported, then it doesn't really cause future conflict. If
you are exporting them, then you would likely want to import and export
them to allow the resolver to substitute them in the future when more
providers are present (check the FAQ on importing and exporting packages
if you aren't familiar with it).
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?
- Are there any other dangers to using either method I didn't outline above?
- Any other options?
I'd always do the second if at all possible. It presents the simplest
overall management, from my point of view. If you are very diligent you
can get either approach to work, but the second approach requires less
diligence.
-> richard
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
