Moving toward bundles - OSGi in Action - page 199

which implies that the packages change at the same rate as the bundle, but some pack-
ages inevitably change faster than others. You may also want to increment the bundle
version because of an implementation fix while the exported API remains at the same
level. Although everything starts out aligned, you'll probably find that you need a sep-
arate version for each package (or at least each group of tightly coupled packages).
We'll take an in-depth look at managing versions in chapter 9, but a classic exam-
ple is the OSG i framework itself, which provides service API s that have changed at dif-
ferent rates over time:

Export-Package: org.osgi.framework;version="1.4",
org.osgi.service.packageadmin;version="1.2",
org.osgi.service.startlevel;version="1.1",
org.osgi.service.url;version="1.0",
org.osgi.util.tracker;version="1.3.3"
Knowing which packages to export is only half of the puzzle of turning a JAR into a bun-
dle—you also need to find out what should be imported. This is often the hardest piece
of metadata to define and causes the most problems when people migrate to OSG i.

6.1.3 Discovering what to import

Do you know what packages a given JAR file needs at execution time? Many developers
have tacit or hidden knowledge of what JAR files to put on the class path. Such knowl-
edge is often gained from years of experience getting applications to run, where you
reflexively add JAR files to the class path until any ClassNotFoundException s disap-
pear. This leads to situations where an abundance of JAR files is loaded at execution
time, not because they're all required, but because a developer feels they may be nec-
essary based on past experience.
The following lines show an example class path for a Java EE client. Can you tell
how these JAR files relate to one another, what packages they provide and use, and
their individual versions?

concurrent.jar:getopt.jar:gnu-regexp.jar:jacorb.jar:\
jbossall-client.jar:jboss-client.jar:jboss-common-client.jar:\
jbosscx-client.jar:jbossha-client.jar:jboss-iiop-client.jar:\
jboss-j2ee.jar:jboss-jaas.jar:jbossjmx-ant.jar:jboss-jsr77-client.jar:\
jbossmq-client.jar:jboss-net-client.jar:jbosssx-client.jar:\
jboss-system-client.jar:jboss-transaction-client.jar:jcert.jar:\
jmx-connector-client-factory.jar:jmx-ejb-connector-client.jar:\
jmx-invoker-adaptor-client.jar:jmx-rmi-connector-client.jar:jnet.jar:\
jnp-client.jar:jsse.jar:log4j.jar:xdoclet-module-jboss-net.jar
With OSG i, you explicitly define which packages your bundle needs, and this knowledge
is then available to any developer who wants it. They no longer have to guess how to com-
pose their class path—the information is readily available in the metadata! It can also
be used by tools such as the OSG i Bundle Repository ( OBR ; http://felix.apache.org/
site/apache-felix-osgi-bundle-repository.html ) to automatically select and validate col-
lections of bundles for deployment.
This means any developer turning a JAR file into a bundle has a great responsibil-
ity in defining the correct set of imported packages. If this list is incomplete or too