Moving toward bundles - OSGi in Action - page 203

Table 6.2 Common optional imported packages found in third-party libraries

Package Used for

GUI classes (could be interactive tests)

javax.swing.*

org.apache.tools.ant.*

ANT taskdefs (build time)

Parsing (maybe build/test related)

antlr.*

sun.misc.*

Sun implementation classes (like BASE64 )

Sun tool support (javac, debugging, and so on)

com.sun.tools.*

list them as dynamically imported packages. For packages you never expect to be used
at execution time, like the Ant packages, we suggest that you either use the optional
attribute or remove them from the list of imported packages. Use resolution:=
optional when you know the bundle will always be used the same way after it's
installed. If you want a more adaptive bundle that reacts to the latest set of available
packages, you should list them as dynamic imports.
If you're new to OSG i and unsure exactly what packages your JAR file uses, consider
using

DynamicImport-Package: *
This makes things similar to the classic model, where requests to load a new class
always result in a query to the complete class path. It also allows your bundle to suc-
cessfully resolve regardless of what packages are available. The downside is that you're
pushing the responsibility of finding the right set of bundles onto users, because you
don't provide any metadata defining what you need! This approach should only be
considered as a stopgap measure to get you started.
You've now chosen the exports and imports for your new bundle. Every non-
optional, nondynamic package you import (but don't export) must be provided by
another bundle. Does this mean that for every JAR file you convert into a bundle, you
also need to convert each of its dependencies into bundles? Not necessarily, because
unlike standard JAR files, OSG i supports embedding JAR files inside bundles.

6.1.4 Embedding vs. importing

Sometimes a JAR file has a close dependency on another JAR file. Maybe they only
work together, or the dependency is an implementation detail you want to keep pri-
vate, or you don't want to share the static member fields in the JAR file with other bun-
dles. In these situations, it makes more sense to embed the dependencies inside the
primary JAR file when you turn it into a bundle. Embedding the JAR file is easier than
converting both JAR files to bundles because you can ignore packages that would oth-
erwise need to be exported and imported between them. The downside of embedding
is that it adds unnecessary weight for non- OSG i users, who can't use the embedded JAR
file unless the bundle is first unpacked. Figure 6.4a shows how a CGLIB bundle might
embed ASM , a small utility for processing byte code.