Java Reference
In-Depth Information
bundle versions with marketing versions, so that major functional improvements
might warrant a change from 2.1 to 3.0, even if those changes are backward compati-
ble. Whichever you choose, we feel that your bundle version should never change by a
smaller increment than any of the packages it exports. If you've made a breaking
change in a package that you provide, then this should be reflected in the bundle's
version, as well as the version of the exported package.
VERSIONS FOR EXPORTED PACKAGES
Versioning
API
packages is extremely important; the version of an exported package is
what allows providers and consumers of that
API
to determine if they're compatible
with it. Semantic versioning is important because it provides detailed information
about the types of changes that have occurred within the
API
. Versioning
API
packages
is also crucial because if two packages have the same name and version, then they need
to be identical. If you don't change your
API
version when the
API
changes, you'll hit the
kinds of problems that feature in the section, “The problem with split packages.”
IMPORT VERSION RANGES
Export versions are usually easy to define. Even if you don't follow the semantic version-
ing scheme (although you definitely should), it isn't too hard to decide on a version
number. Things are less easy when it comes to package imports. This is because package
imports use version ranges to define their future compatibility. In the absence of
semantic versioning this is painfully difficult, but you should still try to pick a range of
versions. What you absolutely
must not do
is add a single version matching the export you
intend to use. For example, the following innocent-looking import is dangerous:
Import-Package: fancyfoods.offers;version="1.0.0"
Doing this says that your application is compatible with
all
future versions of this pack-
age (to infinity). This is extremely unlikely to be true, and causes major problems
when an
API
does eventually make a breaking change.
5.1.2
Scoping your bundles
How many bundles is the right number of bundles? How big should bundles be? The
answer to both questions, unfortunately, is “it depends.” A bundle with one class in it
is probably too small. A bundle with a hundred packages in it is almost certainly too
big. In between those two extremes, however, it's up to you.
The aim of modularization is the same for bundles as it is for objects, high cohe-
sion, and loose coupling. A good bundle is highly cohesive and loosely coupled. Bun-
dles should be tightly focused in what they do, and they should be flexible in how
their dependencies are satisfied. If a single bundle seems to be doing lots of different
things, it's probably too big (incohesive). If it's tightly coupled to another bundle,
then perhaps the two of them should be merged into one bigger bundle, or have
some of their classes redistributed to reduce the coupling.
A bundle's package imports and exports can give a pretty good indication of both
how cohesive it is and how coupled it is to its neighbors. If a bundle has a lot of package
