Moving toward bundles - OSGi in Action - page 218

The third and final bundle contains the rest of the jEdit packages, which we'll call
the engine for now. It should contain all packages beneath the org.gjt.sp namespace,
except the top-level jEdit package and packages under org.gjt.sp.jedit.proto . The
resulting jedit-engine.bnd file is as follows:

-output: jedit-engine.jar

Bundle-Name: jEdit Engine
Bundle-SymbolicName: org.gjt.sp.jedit.engine
Bundle-Version: 4.2

Excludes main
packages

Private-Package:\
!org.gjt.sp.jedit, !org.gjt.sp.jedit.proto.*,\
org.gjt.sp.*
Notice how the same packages listed in the main instructions are negated in the
engine instructions. Refactoring packages between bundles is as simple as moving
entries from one instruction file to another.

STITCHING THE PIECES TOGETHER
You now have three bundles that together form the original class path, but none of
them share any packages. If you tried to launch the OSG i application at this point, it
would fail because of unsatisfied imports between the three bundles. Should you go
ahead and export everything by switching all Private-Package instructions to
Export-Package ? You could, but what would you learn by doing that? Let's try to
export only what you absolutely need to share, keeping as much as possible private.
There are three ways you can find out which packages a bundle must export:

Gain an understanding of the code base and how the packages relate to one
other. This can involve the use of structural analysis tools such as Structure101
( www.headwaysoftware.com/products/structure101/index.php ) .

■

Read the Import-Package headers from generated manifests to compile a list of
packages that “someone” needs to export. Ignore JDK packages like
javax.swing . You can use the bnd print command to avoid having to unpack
the manifest.

■

Repeatedly deploy the bundles into a live framework, and use any resulting
error messages and/or diagnostic commands (such as the diag command on
Equinox) to fine-tune the exported packages until all bundles resolve.

■

The first option requires patience, but the reward is a thorough understanding of the
package structure. It also helps you determine other potential areas that can be
turned into bundles. The third option can be quick if the framework gives you the
complete list of missing packages on the first attempt, but sometimes it feels like an
endless loop of “deploy, test, update.” The second option is a good compromise
between the other two. The bnd tool has already analyzed the code base to come up
with the list of imports, and you already know that the framework will follow the
import constraints listed in the manifest. The structured manifest also means you can
write a script to do the hard work for you.