Java Reference
In-Depth Information
C
A
B
A'
B
A'
D
Bad
Good
Figure 5.1
Bundles that have complex dependencies (like A) can typically only be used in one way, relying
on the dependencies they were compiled with. Bundles with a well-managed dependency graph can (like
the refactored A') be reused in a variety of ways, because it's simple to satisfy their dependency require-
ments.
same library multiple times. One of the first, and most helpful, things you can do to start
getting your sharing right is to get the basics of your bundles right. Unless you do this,
everything else becomes difficult.
5.1.1
Versioning bundles and packages
As we discussed in section 1.2.1, versioning is a fundamental part of
OSG
i. Bundles
and packages have versions, and getting them wrong can cause a lot of trouble. You
can spend a lot of effort producing nice, well-proportioned bundles, but then waste it
all by failing to version your imports and exports properly. A good explanation of the
OSG
i-recommended semantic versioning scheme is in section 12.1.2.
When we say versioning is vital, we mean it. In fact, a badly sized bundle with good
versioning is better than any other bundle without versioning. If you don't provide
version ranges for the packages you import and versions for your exports, it's
impossible
for anyone to reuse your bundle without having to find and install all the dependen-
cies you originally compiled against. Even worse, if any of your bundle's package
dependencies are the same as any of those from any other bundle, and the two bun-
dles need different versions of that package—but don't express that in their package
imports—then the application can't be made to work!
BUNDLE VERSIONS
Versioning bundles is probably the least well-defined versioning practice, and it's cor-
respondingly less important than versioning package imports and exports. You
mustn't let this mislead you into thinking that the bundle version isn't at all impor-
tant. The version of your bundle should indicate to the world how the bundle's fea-
tures and packages have changed over time. This will allow people to easily locate a
bundle version that fits their needs.
How should you decide on a version for your bundle? Some people use the same
semantic versioning principles for bundles as they do for packages, so that a bundle
with backward-compatible changes might change from 2.1 to 2.2, for example,
whereas a breaking change would be indicated by changing 2.1 to 3.0. Others align
