Mastering modularity - OSGi in Action - page 37

clashes. Although the dot-separated construction is enforced by the framework, there's
no way to enforce the reverse-domain-name recommendation. You're free to choose a
different scheme; but if you do, keep in mind that the main purpose is to provide unique
identification, so try to choose a scheme that won't lead to name clashes.
IDENTIFYING THE PAINT PROGRAM (PART 1)
The paint program is divided into bundles based on packages, so you can use each
package as the symbolic name, because they already follow a reverse-domain-name
scheme. For the public API bundle, you declare the symbolic name in manifest file as
Bundle-SymbolicName: org.foo.shape
Although it would be possible to solely use Bundle-SymbolicName to uniquely identify
a bundle, it would be awkward to do so over time. Consider what would happen when
you released a second version of your bundle: you'd need to change the symbolic
name to keep it unique, such as org.foo.shapeV2 . This is possible, but it's cumber-
some; and worse, this versioning information would be opaque to the OSG i frame-
work, which means the modularity layer couldn't take advantage of it. To remedy this
situation, a bundle is uniquely identified not only by its Bundle-SymbolicName but
also by its Bundle-Version , whose value conforms to the OSG i version number format
(see the sidebar “ OSG i version number format”). This pair of attributes not only forms
an identifier, it also allows the framework to capture the time-ordered relationship
among versions of the same bundle.
IDENTIFYING THE PAINT PROGRAM (PART 2)
For example, the following metadata uniquely identifies the paint program's public
API bundle:
Bundle-SymbolicName: org.foo.shape
Bundle-Version: 2.0.0
Although technically only Bundle-SymbolicName and Bundle-Version are related to
bundle identification, the Bundle-ManifestVersion attribute also plays a role. Start-
ing with the R4 specification, it became mandatory for bundles to specify Bundle-
SymbolicName . This was a substantial change in philosophy. To maintain backward
compatibility with legacy bundles created before the R4 specification, OSG i intro-
duced the Bundle-ManifestVersion attribute. Currently, the only valid value for this
attribute is 2 , which is the value for bundles created for the R4 specification or later.
Any bundles without Bundle-ManifestVersion aren't required to be uniquely identi-
fied, but bundles with it must be.
IDENTIFYING THE PAINT PROGRAM (PART 3)
The following example shows the complete OSG i R4 metadata to identify the shape
bundle:
Bundle-ManifestVersion: 2
Bundle-SymbolicName: org.foo.shape
Bundle-Version: 2.0.0