Delving deeper into modularity - OSGi in Action - page 177

curve ball to be thrown into the mix: bundle fragments. Fragments are another way to
deal with split packages by allowing the content of a bundle to be split across multiple,
subordinate bundle JAR files.

5.4 Dividing bundles into fragments

Although splitting packages isn't a good idea, occasionally it does make sense, such as
with Java localization. Java handles localization by using java.util.ResourceBundle s
(which have nothing to do with OSG i bundles) as a container to help you turn locale-
neutral keys into locale-specific objects. When a program wants to convert informa-
tion into the user's preferred locale, it uses a resource bundle to do so. A Resource-
Bundle is created by loading a class or resource from a class loader using a base name,
which ultimately defines the package containing the class or resource for the
ResourceBundle . This approach means you typically package many localizations for
different locales into the same Java package.
If you have lots of localizations or lots of information to localize, packaging all your
localizations into the same OSG i bundle can result in a large deployment unit. Addi-
tionally, you can't introduce new localizations or fix mistakes in existing ones without
releasing a new version of the bundle. It would be nice to keep localizations separate;
but unlike the split package support of Require-Bundle , these split packages gener-
ally aren't useful without the bundle to which they belong. OSG i provides another
approach to managing these sorts of dependencies through bundle fragments. We'll
come back to localization shortly when we present a more in-depth example, but first
we'll discuss what fragments are and what you can do with them.

5.4.1 Understanding fragments

If you recall the modularity discussion in chapter 2, you know there's a difference
between logical modularity and physical modularity. Normally, in OSG i, a logical mod-
ule and a physical module are treated as the same thing; a bundle is a physical module
as a JAR file, but it's also the logical module at execution time forming an explicit visi-
bility encapsulation boundary. Through fragments, OSG i allows you to break a single
logical module across multiple physical modules. This means you can split a single
logical bundle across multiple bundle JAR files.
Breaking a bundle into pieces doesn't result in a handful of peer bundles; instead,
you define one host bundle and one or more subordinate fragment bundles. A host
bundle is technically usable without fragments, but the fragments aren't usable with-
out a host. Fragments are treated as optional host-bundle dependencies by the OSG i
framework. But the host bundle isn't aware of its fragments, because it's the fragments
that declare a dependency on the host using the Fragment-Host manifest header.

FRAGMENT-HOST This header specifies the single symbolic name of the host bundle
on which the fragment depends, along with an optional bundle version range.

A fragment bundle uses the Fragment-Host manifest header like this:

Fragment-Host: org.foo.hostbundle; bundle-version="[1.0.0,1.1.0)"