Building bundles - OSGi in Action - page 514

Bnd is different because it takes a pull approach to assembling bundles: it doesn't
just archive everything it's given. Developers write instructions using OSG i-style head-
ers, which can either be written as properties in the build or stored in separate property
files. The bnd tool uses these instructions to pick the classes and resources that should
go into each bundle. Because the tool knows each class and resource pulled into a bun-
dle, it can make sure they form a consistent set and generate a valid OSG i manifest that
represents the contents. It can also glean information from other bundles on the class
path, such as version information, and use that to automatically version imports.
Bnd instructions can be categorized into four types:
■ OSG i-style headers, which start with a capital letter
■ Low-level directives, which start with a dash
■ Variables, which start with a lowercase letter
■ Built-in macros, which start with $
Let's begin by looking at what headers are available.

A.1.2 Headers

Bnd headers follow the same pattern of comma-separated clauses defined in the OSG i
specification, so you don't have to learn yet another syntax to write instructions. The
bnd tool accepts standard OSG i headers such as Export-Package and Import-Pack-
age , as well as its own headers like Private-Package and Include-Resource that let
you define additional bundle contents that are neither imported nor exported. To
make life easier, you can use wildcard patterns and negation in package headers; you
don't have to be explicit and list every single package in detail. Bnd expands wildcards
and normalizes versions, so the final bundle always has valid OSG i headers.
The following are some of the bnd headers you've used so far in this topic.

E XPORT -P ACKAGE
This header is a comma-separated list of packages that should be contained and
exported from this bundle. By default, this is * , which pulls the complete class path
into the bundle. This is fine when you're creating a mega bundle, but you'll usually
want to limit the packages pulled into the bundle and give them an explicit version:

Export-Package: org.foo;version=1.0
If you want to export all packages except any internal or implementation packages,
you can use a negated pattern. But remember that the negated pattern must appear
before the normal pattern, because the bnd tool processes patterns from left to right:

Export-Package: !*.internal.*,!*.impl.*,org.foo;version=1.0
As discussed in chapter 5, it's often a good idea to import your own exported API pack-
ages. Older versions of bnd automatically added imports for all exports, whereas the
latest versions try to make better guesses about which exported packages should be
imported. If you don't want to import an exported package, you can add an attribute
to each clause as follows:

Export-Package: org.foo;version=1.0;-noimport:=true