Packaging your enterprise OSGi applications - Enterprise OSGi in Action - page 90

require different versions of the same common library? If the packages and class
names are the same, one version will always come before the other one on the class-
path. If the two versions have different sets of capabilities—or different sets of bugs—
there may be runtime problems which are quite tricky to debug. The only solution for
this problem is to repackage, redesign, or re-engineer the EAR s and move the right
version of each shared library back into an EAR . This can be particularly problematic
for modules that you don't have the source for.

4.1.2 Enterprise OSGi applications

In Java EE , the application packaging role is fulfilled by the EAR . Until recently, in
OSG i there was no similar concept; application packaging units began and ended with
bundles. As we've already mentioned, bundles aren't a suitable packaging unit for
large-scale applications. A typical application will be developed as several bundles,
each with a well-defined API . In a standard OSG i framework, these bundles will need
to be individually installed, which is far from ideal.
The lack of an aggregate deployment artifact in core OSG i is only one of its limita-
tions. As we've previously discussed, OSG i provides an excellent platform for sharing
code between different applications; however, because you never know what other
bundles you might find in a framework, you often have no choice but to send all the
bundles you might need to the application deployer, even though many of them may
not be needed at runtime.
One final problem with enterprise OSG i application packaging is that it's possible to
have too much sharing! While sharing common API s and libraries is a good idea, there
are some parts of an application that are distinctly private. This may seem counterintu-
itive at first, but an enterprise OSG i application is a bit like a larger version of an OSG i
bundle where, instead of packages, you have modules. Some modules you're happy to
have provided to you, like a bundle importing a package; some modules you're happy
to provide to the outside world, like a bundle exporting a package. Most importantly,
there are some modules (like your internal payment processing implementation) that
you don't want other applications to be able to use! Application multitenancy is awkward
in core OSG i frameworks, because there's only one level of granularity.
Don't let the previous paragraphs put you off. It's true that enterprise OSG i has
some hurdles to overcome when it comes to application packaging, but as with many
other problems in software engineering, there are some interesting solutions in open
source, and useful new specifications. Let's start with a new standard for application
packaging: subsystems .

4.2 Enterprise OSGi subsystems

OSG i subsystems are a new concept in release 5 of the OSG i Enterprise Specification.
Subsystems are a more general concept than OSG i applications, which is why they're
called subsystems, and not applications! Although they solve many of the same prob-
lems, subsystems are also definitely more than an OSG i equivalent to EAR s. Subsystems