Mastering modularity - OSGi in Action - page 53

defined by the OSG i specification but is a feature of the bundle launcher. To build and
launch the newly modularized paint program, go into the chapter02/paint-modular/
directory in the companion code and type ant . Doing so compiles all the code and pack-
ages the modules. Typing java -jar launcher.jar bundles/ starts the paint program.
The program starts up as it apparently always has; but underneath, the OSG i frame-
work is resolving the bundles' dependencies, verifying their consistency, and enforc-
ing their logical boundaries. That's all there is to it. You've now used the OSG i module
layer to create a nicely modular application. OSG i's metadata-based approach didn't
require any code changes to the application, although you did move some classes
around to different packages to improve logical and physical modularity.
The goal of the OSG i framework is to shield you from a lot of the complexities; but
sometimes it's beneficial to peek behind the curtain, such as to help you debug the
OSG i-based applications when things go wrong. In the next section, we'll look at some
of the work the OSG i framework does for you, to give you a deeper understanding of
how everything fits together. Afterward, we'll close out the chapter by summarizing
the benefits of modularizing the paint program.

2.7 OSGi dependency resolution

You've learned how to describe the internal code composing the bundles with Bundle-
ClassPath , expose internal code for sharing with Export-Package , and declare depen-
dencies on external code with Import-Package . Although we hinted at how the OSG i
framework uses the exports from one bundle to satisfy the imports of another, we didn't
go into detail. The Export-Package and Import-Package metadata declarations
included in bundle manifests form the backbone of the OSG i bundle dependency
model, which is predicated on package sharing among bundles.
In this section, we'll explain how OSG i resolves bundle package dependencies and
ensures package consistency among bundles. After this section, you'll have a clear
understanding of how bundle modularity metadata is used by the OSG i framework. You
may wonder why this is necessary, because bundle resolution seems like an OSG i frame-
work implementation detail. Admittedly, this section covers some of the more complex
details of the OSG i specification; but it's helpful when defining bundle metadata if you
understand a little of what's going on behind the scenes. Further, this information can
come in handy when you're debugging OSG i-based applications. Let's get started.

2.7.1 Resolving dependencies automatically

Adding OSG i metadata to your JAR files represents extra work for you as a developer,
so why do it? The main reason is so you can use the OSG i framework to support and
enforce the bundles' inherent modularity. One of the most important tasks per-
formed by the OSG i framework is automating dependency management, which is
called bundle dependency resolution .
A bundle's dependencies must be resolved by the framework before the bundle can
be used, as shown in figure 2.15. The framework's dependency resolution algorithm is
sophisticated; we'll get into its gory details, but let's start with a simple definition.