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
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.
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
Search WWH ::