Mastering modularity - OSGi in Action - page 43

program shape API bundle is as follows (figure 2.11 shows how
we'll graphically represent exported module packages):

Export-Package: org.foo.shape
Here, you're exporting every class in the org.foo.shape
package. You'll likely want to export more than one package
at a time from your bundles. You can export multiple pack-
ages by separating them with commas:

export
org.foo.shape

Figure 2.11 Graphical
depiction of an exported
package

Export-Package: org.foo.shape,org.foo.other
You can also attach attributes to exported packages. Because it's possible for different
bundles to export the same packages, a given bundle can use attributes to differenti-
ate its exports from other bundles. For example:

Export-Package: org.foo.shape; vendor="Manning", org.foo.other;
vendor="Manning"
This attaches the vendor attribute with the value "Manning" to the exported packages.
In this particular example, vendor is an arbitrary attribute because it has no special
meaning to the framework—it's something we made up. When we talk about import-
ing code, you'll get a better idea of how arbitrary attributes are used in package shar-
ing to differentiate among exported packages. As we mentioned previously in the
sidebar “ JAR file manifest syntax,” OSG i also supports a shorthand format when you
want to attach the same attributes to a set of target packages, like this:

Export-Package: org.foo.shape; org.foo.other; vendor="Manning"
This is equivalent to the previous example. This shorthand comes in handy, but it can
be applied only if all attached attributes are the same for all packages. Using arbitrary
attributes allows a bundle to differentiate its exported packages, but there's a more
meaningful reason to use an attribute for differentiation: version management.
Code is constantly evolving. Packages contain classes that change over time. It's
important to document such changes using version numbers. Version management
isn't a part of standard Java development, but it's inherent in OSG i-based Java develop-
ment. In particular, OSG i supports not only bundle versioning, as discussed previously,
but also package versioning , which means every shared package has a version number.
Attributes are used to associate a version number with a package:

Export-Package: org.foo.shape; org.foo.other; version="2.0.0"
Here, you attach the version attribute with the value "2.0.0" to the exported pack-
ages, using OSG i's common version-number format. In this case, the attribute isn't
arbitrary, because this attribute name and value format is defined by the OSG i specifi-
cation. You may have noticed that some of the earlier Export-Package examples don't
specify a version. In that case, the version defaults to "0.0.0" , but it isn't a good idea
to use this version number. We'll discuss versioning in more detail in chapter 9.