Mastering modularity - OSGi in Action - page 44

With Bundle-ClassPath and Export-Package , you have a pretty good idea how to
define and control the visibility of the bundle's internal classes; but not all the code
you need will be contained in the bundle JAR file. Next, you'll learn how to specify the
bundle's dependencies on external code.

IMPORTING EXTERNAL CODE
Both Bundle-ClassPath and Export-Package deal with the visibility of internal bun-
dle code. Normally, a bundle is also dependent on external code. You need some way
to declare which external classes are needed by the bundle so the OSG i framework can
make them visible to it. Typically, the standard Java class path is used to specify which
external code is visible to classes in your JAR files, but OSG i doesn't use this mecha-
nism. OSG i requires all bundles to include metadata explicitly declaring their depen-
dencies on external code, referred to as importing .
Importing external code is straightforward, if not tedious. You must declare
imports for all packages required by your bundle but not contained in your bundle.
The only exception to this rule is for classes in the java.* packages, which are auto-
matically made visible to all bundles by the OSG i framework. The manifest header you
use for importing external code is appropriately named Import-Package .

IMPORT-PACKAGE A comma-separated list of packages needed by internal
bundle code from other bundles.

Import-Package vs. import keyword
You may be thinking that you already do imports in your source code with the import
keyword. Conceptually, the import keyword and declaring OSGi imports are similar,
but they serve different purposes. The import keyword in Java is for namespace man-
agement; it allows you to use the short name of the imported classes instead of us-
ing its fully qualified class name (for example, you can refer to SimpleShape rather
than org.foo.shape.SimpleShape ). You can import classes from any other pack-
age to use their short name, but it doesn't grant any visibility. In fact, you never need
to use import , because you can use the fully qualified class name instead. For OSGi,
the metadata for importing external code is important, because it's how the frame-
work knows what your bundle needs.

The value of the Import-Package header follows the common OSG i manifest header
syntax. First, let's start with the simplest form. Consider the main paint program bun-
dle, which has a dependency on the org.foo.shape package.
It needs to declare an import for this package as follows (fig-
ure 2.12 shows how we'll graphically represent imported
module packages):

import
org.foo.shape

Import-Package: org.foo.shape
This specifically tells the OSG i framework that the bundle
requires access to org.foo.shape in addition to the internal

Figure 2.12 Graphical
depiction of an imported
package