Tools for building and testing - Enterprise OSGi in Action - page 196

package to 1.0.0 (as we did in chapter 2), it's sufficient to create the following
package-info.java file in that package:
@Version("1.0.0")
package fancyfoods.food;
import aQute.bnd.annotation.Version;
But you can do even better than that. The semantic versioning scheme suggests
adding a fourth qualifier part to the version string to identify the individual build.
While generating the manifest, bnd will automatically expand variables in the
package-info.java files:
@Version("1.0.0.${buildLabel}")
package fancyfoods.food;
import aQute.bnd.annotation.Version;
To set the build label, add the following to the bnd.bnd file:
buildLabel = build-${tstamp}
Even more usefully, bnd will automatically add version ranges to its package imports. It
does this based, not on information you provide, but rather on what's in the manifest
of the bundles on the build path. Bnd will work out an appropriate version range based
on the semantic versioning policy. API implementation providers will be less tolerant to
changes in the API than consumers of the API , so you'll need to give bnd a hint to
choose the right range for API providers. Explicitly including the API package in the
Import-Package list and adding the provide:=true directive will do the trick. API pro-
viders will import packages between versions on the classpath up to, but not including,
the next minor increment. Other consumers of an API can handle versions up to, but
not including, the next major version. If you're at all confused about the difference
between consumers and providers, or why they need different version ranges, then we
suggest taking a look at appendix A (A.2.5), as well as looking back at section 1.2.1.
SETTING THE CLASSPATH FOR BND
How does bnd work out what version you're importing? When you repackaged the
fancyfoods.persistence bundle, no versions were specified for the imported pack-
ages, because bnd didn't have access to them (or rather, to their exporting bundles).
To allow bnd to work out package versions, bnd needs to see both the compiled
classes and the compile-time classpath. These two groups of classes are collapsed into
a single bnd classpath. Bnd will read Eclipse .classpath files to work out a default class-
path, but it won't unpack Eclipse classpath containers (like those used by Eclipse
PDE ). If you're not using Eclipse, or if bnd is struggling to interpret the Eclipse class-
path files, classpaths can be specified using the -classpath option.
The lack of a distinction between the compiled classes for the target bundle and
the classpath used to compile those classes is why it's necessary to specify the Private-
Package header. Otherwise, bnd won't have any way of knowing which classes belong
to the bundle it's building. It also means caution must be exercised when using