Java Reference
In-Depth Information
Notice that unlike the standard OSG i headers, bnd package instructions can contain
wildcards and negative patterns. Bnd expands these patterns at build time according
to what it finds in the project byte code on the class path, saving you the hassle of typ-
ing everything in minute detail.
After you've chosen your exported and internal packages, you invoke the bnd
build task by passing it the original BeanUtils JAR file along with your custom bnd
instructions:
$ cd chapter06/BeanUtils-example
$ java -jar ../../lib/bnd-0.0.384.jar \
build -classpath commons-beanutils-1.8.0.jar beanutils.bnd
Bnd processes the given class path using your instructions and generates a new JAR
alongside the instructions file, called beanutils.jar. You can extract the OSG i-enhanced
manifest from the newly created BeanUtils bundle like so:
$ java -jar ../../lib/bnd-0.0.384.jar \
print -manifest beanutils.jar
As you can see, it contains the following generated list of imported packages:
Import-Package:
org.apache.commons.beanutils;version="1.8",
org.apache.commons.beanutils.converters;version="1.8",
org.apache.commons.beanutils.expression;version="1.8",
org.apache.commons.beanutils.locale;version="1.8",
org.apache.commons.beanutils.locale.converters;version="1.8",
org.apache.commons.collections,
org.apache.commons.collections.comparators,
org.apache.commons.collections.keyvalue,
org.apache.commons.collections.list,
org.apache.commons.collections.set,
org.apache.commons.logging
There are a couple of interesting points about this list. First, bnd has added imports for
all the BeanUtils packages that you want to export. As we discussed in section 5.1.1, this
is usually good practice when exporting an API that has multiple implementations,
because it means that if (for whatever reason) an existing bundle already exports these
packages, you'll share the same class space for the API . Without these imports, your bun-
dle would sit on its own little island, isolated from any bundles already wired to the pre-
vious package exporter. But if you don't expect alternative implementations of
Commons Collections, you can always turn off this feature with a special bnd directive:
Export-Package: org.apache.commons.beanutils.*;-noimport:=true
Bnd has also found byte code references to the Apache Collections and Logging pack-
ages, which aren't contained in the BeanUtils bundle and must therefore be
imported. Just think: you can now tell what packages a JAR file needs at execution
time by checking the imported package list in the manifest. This is extremely useful
for automated deployment of applications. Such a system knows that when deploying
Search WWH ::




Custom Search