Mastering modularity - OSGi in Action - page 57

Bundle-Name: Paint API
Export-Package: org.foo.shape
Import-Package: javax.swing; vendor="Sun"
Attempting to resolve the paint program bundle now fails because no bundle is export-
ing the package with a matching vendor attribute for the API bundle. Putting the
vendor attribute back on the Swing bundle export allows the main paint program bun-
dle to successfully resolve again with the same wiring, as shown earlier in figure 2.16.
Attributes on exported packages have an impact only if imported packages specify
them, in which case the values must match or the resolve fails.
Recall that we also talked about the version attribute. Other than the more
expressive interval notation for specifying ranges, it works the same way as arbitrary
attributes. For example, you can modify the shape API bundle as follows:
Bundle-Name: Paint API
Export-Package: org.foo.shape; vendor="Manning"; version="2.0.0"
Import-Package: javax.swing; vendor="Sun"
And you can modify the paint program bundle as follows:
Bundle-Name: Simple Paint Program
Import-Package: org.foo.shape; vendor="Manning"; version="[2.0.0,3.0.0)"
In this case, the framework can still resolve everything because the shape API bun-
dle's export matches the paint program bundle's import; the vendor attributes
match, and 2.0.0 is in the range of 2.0.0 inclusive to 3.0.0 exclusive. This particular
example has multiple matching attributes on the import declaration, which is treated
like a logical AND by the framework. Therefore, if any of the matching attributes on
an import declaration don't match a given export, the export doesn't match at all.
Overall, attributes don't add much complexity to the resolution process, because
they add additional constraints to the matching of imported and exported package
names already taking place. Next, we'll look into slightly more complicated bundle-
resolution scenarios.
MULTIPLE MATCHING PACKAGE PROVIDERS
In the previous section, dependency resolution is fairly straightforward because
there's only one candidate to resolve each dependency. The OSG i framework doesn't
restrict bundles from exporting the same package. Actually, one of the benefits of the
OSG i framework is its support for side-by-side versions, meaning it's possible to use dif-
ferent versions of the same package in the same running JVM . In highly collaborative
environments of independently developed bundles, it's difficult to limit which ver-
sions of packages are used. Likewise, in large systems, it's possible for different teams
to use different versions of libraries in their subsystems; the use of different XML
parser versions is a prime example.
Let's consider what happens when multiple candidates are available to resolve the
same dependency. Consider a case in which a web application needs to import the
javax.servlet package and both a servlet API bundle and a Tomcat bundle provide
the package (see figure 2.17).