Mastering modularity - OSGi in Action - page 46

you to specify an explicit version range using interval notation, where the characters
[ and ] indicate inclusive values and the characters ( and ) indicate exclusive values.
Consider the following example:

Import-Package: org.osgi.framework; version="[1.3.0,2.0.0)"
This statement declares an import for package org.osgi.framework for the version
range including 1.3.0 and up to but excluding 2.0.0 and beyond. Table 2.2 illustrates
the meaning of the various combinations of the version range syntax.

Syntax Meaning

min <_ x < max

"[min,max)"

"[min,max]"

min <_ x <_ max

min < x < max

"(min,max)"

"(min,max]"

min < x <_ max

Table 2.2 Version range
syntax and meaning

min <_ x

"min"

If you want to specify a precise version range, you must use a version range like
"[1.0.1,1.0.1]" . You may wonder why a single value like "1.0.1" is an infinite range
rather than a precise version. The reason is partly historical. In the OSG i specifications
prior to R4, all packages were assumed to be specification packages where backward
compatibility was guaranteed. Because backward compatibility was assumed, it was only
necessary to specify a minimum version. When the R4 specification added support for
sharing implementation packages, it also needed to add support for arbitrary version
ranges. It would have been possible at this time to redefine a single version to be a precise
version, but that would have been unintuitive for existing OSG i programmers. Also, the
specification would have had to define syntax to represent infinity. In the end, the OSG i
Alliance decided it made the most sense to define versions ranges as presented here.
You may have noticed that some of the earlier Import-Package examples didn't
specify a version range. When no version range is specified, it defaults to the value
"0.0.0" , which you may expect from past examples. Of course, the difference here is
that the value "0.0.0" is interpreted as a version range from 0.0.0 to infinity.
Now you understand how to use Import-Package to express dependencies on
external packages and Export-Package to expose internal packages for sharing. The
decision to use packages as the basis for interbundle sharing isn't an obvious choice to
everyone, so we discuss some arguments for doing so in the sidebar “Depending on
packages, not bundles.”
We've now covered the major constituents of the OSG i module layer: Bundle-
ClassPath , Export-Package , and Import-Package . We've discussed these in the con-
text of the paint program you'll see running in the next section, but the final piece of
the puzzle we need to look at is how these various code-visibility mechanisms fit
together in a running application.