Java Reference
In-Depth Information
foo;version="2.0"
Versioning the bundle and
packages in lock step
Provider
version="
2.0"
bar;version="2.0"
foo;version="1.0"
Provider
version="
1.0"
bar;version="1.0"
Client
version="2.0"
foo;version="2.0"
Client
version="1.0"
bar;version="1.0"
Provid
er
version="2.0"
Versioning the bundle and
packages independently
Client
version="1.0"
Figure 9.1
Versioning
packages independently
A counterargument is that if the bundle is highly cohesive, it makes no sense to
update a single package without its siblings. Although this is true, it's not uncommon
for
JAR
files to be less than optimally cohesive.
OSG
i already caters to this situation
with
uses
constraints, which we introduced in chapter 2. These constraints ensure
that the cohesiveness of packages is maintained by capturing internal package depen-
dencies. This means upstream users aren't forced to depend on anything more than
the
API
-level contract of the exported packages.
Luckily, in
OSG
i, you can version your packages either independently or in lock-
step with the bundle, as shown in figure 9.1. The
OSG
i approach of package-level ver-
sioning and dependencies leads to less churn in the development lifecycle. Less churn
implies less risk, because existing modules are better understood than updated mod-
ules, which may introduce unexpected behavior into a complex system. This concept
is extremely powerful and removes a lot of the pain from assembling applications out
of independent
JAR
files, because you can make better-informed decisions about when
and what to update.
MULTIPLE VERSIONS IN THE SAME JVM
Package-level versioning is also helpful when it comes to running different versions
side by side. Java doesn't explicitly support this by default, but
OSG
i does. In many
cases, this seemingly unimportant feature frees you from worrying about backward
compatibility or changes to artifacts outside your control. Your bundles can continue
to use the versions of packages with which they're compatible, because your entire
application no longer has to agree on a single version to place on the class path.
