Coping with the non-OSGi world - Enterprise OSGi in Action - page 297

In the simplest case, you can wrap the chocolate department JAR by pointing bnd at it
and invoking the wrap command, as follows:

java -jar biz.aQute.bnd.jar wrap
fancyfoods.department.chocolate_1.0.0.jar
This will create an OSG i bundle called fancyfoods.department.chocolate_1.0.0.bar. If
you forget the naming convention and look on your filesystem for a new JAR file, it
may take you some time to find the wrapped JAR ! When you've found the generated
bundle, you should see that it contains a manifest that looks something like the follow-
ing listing.

Listing 12.1 A bnd-generated default manifest

Manifest-Version: 1
Bnd-LastModified: 1309600295603
Bundle-Blueprint: OSGI-INF/blueprint/*.xml
Bundle-ManifestVersion: 2
Bundle-Name: fancyfoods.department.chocolate_1.0.0
Bundle-SymbolicName: fancyfoods.department.chocolate_1.0.0
Bundle-Version: 1.0.0
Created-By: 1.6.0 (IBM Corporation)
Export-Package: fancyfoods.chocolate;uses:="fancyfoods.food,fancyfoods.o
ffers",OSGI-INF,OSGI-INF.blueprint
Import-Package: fancyfoods.food;resolution:=optional,fancyfoods.offers;r
esolution:=optional
Tool: Bnd-1.44.0
If you inspect the manifest bnd has generated, you'll see that bnd has wrapped the
chocolate department JAR into a bundle in the least restrictive way possible; every
package in the JAR is freely exported, and every imported package is optional. If you
look closely, you'll see that the bundle manifest is even less restrictive than you might
have expected. The exports for the bundle are so loose that it even exports its OSGI-
INF and OSGI-INF /blueprint folders!
Bnd has a good reason for being so unrestrictive. These defaults mean the gener-
ated bundle is guaranteed to start in any OSG i environment, but they don't guarantee
that the bundle will work properly! The optional imports and generous exports give
you an OSG i bundle with the character of a conventional JAR , where all classes are
externally visible and missing dependencies won't be detected until classes fail to load
at runtime.
As you know, you aren't using OSG i to make things work like they do with normal
Java! It's at this point where hopefully you'll understand why we covered building
OSG i bundles by hand in section 12.1.2, before looking at automated tools. Every tool
needs some level of configuration to produce a sensible result, and that configuration
needs to be built with at least a vague understanding of the bundling process.
Fortunately, you can easily refine the bundle bnd produces by using a bnd file in the
wrapping process. As a starting point, you may want to set a sensible symbolic name and
version; you'll notice that the default symbolic name for your bundle is particularly