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

seven bundles to remember to install. It's time to look at how you can package your
application in a more convenient form.
Packaging an application has changed over time, in much the same way as writing
an application has. Originally programs were small, and could easily be packaged as a
single binary file. As programs grew in complexity, they also grew in size and were split
into a number of discrete units, usually based on function. As Java developers, you'll
already be familiar with the concept of a JAR file and should also understand the struc-
ture of an OSG i bundle.
JAR s and bundles are examples of coarse-grained packaging but, as you have
already seen, they aren't coarse enough to describe an entire application. Most of this
chapter is dedicated to describing application packaging concepts. With an under-
standing of the basic concepts behind enterprise OSG i application packaging, it
becomes a straightforward exercise to package any application. To start with, let's try
to understand the problem that application packaging is trying to solve. Why do you
need something bigger than a bundle?

4.1 The need for more than modules

The OSG i specifications have described the interactions of bundles as a means for
packaging code for many years, and before that the Java JAR specification defined a
mechanism by which groups of classes could be delivered in a single unit. As a special-
ization of a JAR file, an OSG i bundle offers no greater structure than is present in Java
SE . A single binary file may contain many classes or resources, logically arranged into
packages, but it represents the largest packaging unit that can be deployed.
Because of their complex requirements and core business value, enterprise appli-
cations are usually quite large, and often are developed by distributed teams. Even if
the entire development team works in the same location, in order for them to work
effectively, it's typical to develop the application as a set of modules ( JAR s) rather than
as a single monolithic unit.
It's almost certain that there will be classes that need to be shared between the
individual modules of the application, but shouldn't be shared with other applica-
tions. If application internals are allowed onto the classpath of other applications, the
encapsulation of the application as a whole will be poor, even if the individual bun-
dles are nicely encapsulated. Multibundle applications can also behave unpredict-
ably in multitenanted systems. Applications may also get inappropriate visibility of
utility libraries from other applications. If the versions are incompatible, or if state is
stored statically, this classpath contamination can have disastrous effects that surface
only in production.
As you learned in chapter 1, modularity is good, and so it would be a shame to col-
lapse that complex enterprise application back into a single JAR file to distribute it
and ensure encapsulation. Java EE recognized this problem early in its development,
and created the Enterprise Archive ( EAR ) .