Java Reference
In-Depth Information
Like a
PAR
file, a plan file provides no guarantees that missing dependencies
will be satisfied when it's installed. Any dependencies must be listed at some
scope within the application. This approach is brittle because you must encode
the name of the bundle that provides your dependency, rather than the pack-
ages that need to be provided.
■
PAR
files and plan files are, in many ways, similar to the
EBA
model, and in combina-
tion can be used to achieve almost identical results to
EBA
deployment. There are a
few ways to look at this. One mean-hearted way to look at it is to say that the
EBA
was a
case of
not invented here
syndrome; another, slightly kinder, viewpoint would be that an
EBA
is a restatement of
PAR
and plan files to provide all the benefits within a single
packaging. In our (not completely unbiased) perspective, we suggest that there's one
other
EBA
idiom that's completely absent from the
PAR
/plan model, which is the con-
cept of inclusion by version range. Both
PAR
and plan files require you to specify spe-
cific versions at development time. There's no flexibility for future bug fixes or feature
enhancements. New code can't be delivered as a new bundle, only as a completely
new application.
SpringSource dm Server/Eclipse Virgo isn't the only
OSG
i application platform
available that doesn't make use of
EBA
packaging. Another popular platform is
Apache Karaf, with its feature model.
4.4.2
Apache Karaf features
Karaf features are another way of describing an
OSG
i application, and are rather similar
to a plan file from Spring dm Server. Like plan files, Karaf features use
XML
to describe
the set of modules that are to be deployed. One key difference between Karaf features
and the other application packaging artifacts we've been looking at is that a single
XML
file may define multiple features (applications). Even more flexibly, features can
depend on other features. These things are definitely not possible in Java
EE
EAR
s.
Because of their ability to define multiple features, Karaf features are sometimes
referred to as repositories. Each feature in the repository defines the bundles that
should be installed to activate the feature, because with plan files, the bundles are
referred to directly with no version range. One advantage of features over plan files is
that the bundles are defined as references within a Maven repository. The modules
referred to don't even have to be bundles; native
JAR
files can be automagically
wrapped into
OSG
i bundles.
Although wrapping a
JAR
might seem like the best feature in the world, allowing
the benefits of
OSG
i without any effort from the developer, it should be noted that
there are some big drawbacks. Automatic wrapping of bundles means there's no way
to distinguish an
API
from internals, so it typically exposes everything from the
JAR
.
It's also difficult to determine the dependencies of an arbitrary
JAR
file, so the imports
for a wrapped bundle aren't always correct. Automatic wrapping also has no context
for determining the versions at which packages should be exported, nor the version
ranges that should be used for imports. Finally, wrapping a
JAR
at runtime leaves no
