Mastering modularity - OSGi in Action - page 31

easy to implement new, possibly third-party shapes for use with the program. Unfortu-
nately, SimpleShape is in the same package as the program's implementation classes.
To r e m e d y t h i s s i t u a t i o n , y o u ' l l s h u f f l e t h e p a c k a g e s t r u c t u r e s l i g h t l y. Yo u ' l l m o v e
SimpleShape into the org.foo.shape package and move all shape implementations
into a new package called org.foo.shape.impl . These changes divide the paint pro-
gram into three logical pieces according to the package structure:
■ org.foo.shape —The public API for creating shapes
■ org.foo.shape.impl —Various shape implementations
■ org.foo.paint —The application implementation
Given this structure (logical modularity), you could package each of these packages as
separate JAR files (physical modularity). To have OSG i verify and enforce the modular-
ity, it isn't sufficient to package the code as JAR files: you must package them as bun-
dles. To do this, you need to understand OSG i's bundle concept, which is its logical
and physical unit of modularity. Let's introduce bundles.

2.4 Introducing bundles

If you're going to use OSG i technology, you may as well start getting familiar with the
term bundle , because you'll hear and say it a lot. Bundle is how OSG i refers to its specific
realization of the module concept.
Throughout the remainder of this topic,
the terms module and bundle will be used
interchangeably; but in most cases we're
specifically referring to bundles and not
modularity in general, unless otherwise
noted. Enough fuss about how we'll use
the term bundle —let's define it.

.class

Class files

BUNDLE A physical unit of modularity
in the form of a JAR file containing
code, resources, and metadata, where
the boundary of the JAR file also serves
as the encapsulation boundary for log-
ical modularity at execution time.

.xml
.jpg
etc.

Bundle

Resource files

The contents of a bundle are graphically
depicted in figure 2.6. The main thing that
makes a bundle JAR file different than a
normal JAR file is its module metadata,
which is used by the OSG i framework to
manage its modularity characteristics. All
JAR files, even if they aren't bundles, have
a place for metadata, which is in their
manifest file or, more specifically, in the

Manifest.mf

Metadata

Figure 2.6 A bundle can contain all the usual
artifacts you expect in a standard JAR file. The
only major difference is that the manifest file
contains information describing the bundle's
modular characteristics.