Managing bundles - OSGi in Action - page 293

most important skills you'll need to fully master OSG i. In this chapter, we'll explore
different aspects of bundle management, including the following:

Evolving a bundle using versioning policies

■

Managing a bundle's configuration data

■

Configuring a bundle's activation policy

■

With these skills, you'll be better equipped to deploy and manage bundles in various
application configurations. Let's start by looking at versioning.

9.1 Versioning packages and bundles

From what you've learned so far, you know that versioning is a core part of any OSG i
application. Both bundles and their exported packages have versions. When the
framework resolves bundle dependencies, it takes these versions into account. In this
section, we'll discuss the recommended policy for versioning these artifacts and dis-
cuss advantages and disadvantages of different versioning strategies. To get things
started, let's provide some motivation for OSG i's approach to versioning.

9.1.1 Meaningful versioning

In traditional Java programming, versioning is an afterthought. OSG i, on the other
hand, treats versioning as a first-class citizen, which makes it easier to handle version-
ing in a meaningful way. This emphasis on versioning means that a proper versioning
strategy is important for maintaining application consistency.
You must be thinking, “Hey! I already version my JAR files!” Tools like Maven and Ivy
let you specify versions for JAR files and declare dependencies on those versions. These
tools work with module-level dependencies, which we talked about in chapters 2 and 5.
You know that module-level dependencies are brittle when it comes to expressing fine-
grained dependencies between units of code.
Likewise, applying versions only at the module level has some drawbacks. Such a
model is too simple and forces all packages in a JAR file to be versioned in lockstep
with the other packages. Let's look at some of these issues in more detail.

MODULE VERSIONING IS OPAQUE
Consider a case where you bundle related packages together and assign a version
number to the resulting JAR file. Later, you may need to alter some code in one of the
contained packages; such a change may be the result of a bug fix or a change to the
API contract. This new JAR file needs a new version number associated with it.
With a single version number for all the packages, it's left to upstream users of the
JAR file to decide whether the change warrants their making the update. Because the
only information they have is the module-level version-number change, it's often a
stab in the dark as to whether the updated functionality is required for their applica-
tion. Upstream users don't typically use all the functionality provided by a JAR file and
depend on only a subset of it. Depending on which subset they use, it's possible that
nothing of importance has changed for them.