Java Reference
In-Depth Information
It's possible to use attributes on your package exports to differentiate them, but this
requires a corresponding attribute on the import. In the example manifests shown
next, the importing bundle
A
will wire to the package from
B
and get
fancy-
foods.split.Foo
every time:
Bundle-SymbolicName: A
Import-Package: fancyfoods.split;type="top"
Bundle-SymbolicName: B
Export-Package: fancyfoods.split;type="top"
Bundle-SymbolicName: C
Export-Package: fancyfoods.split;type="bottom"
Another way of differentiating the two packages is to explicitly select a providing bun-
dle, either with the
bundle-symbolicname
or
bundle-version
attributes. These are
the only way to choose a particular provider that doesn't specify any attributes:
Bundle-SymbolicName: A
Import-Package: fancyfoods.split;bundle-symbolicname="B"
Bundle-SymbolicName: B
Export-Package: fancyfoods.split
Bundle-SymbolicName: C
Export-Package: fancyfoods.split
Although using attributes does allow you to pick one export or the other, it's far from
elegant. Using the
bundle-symbolicname
attribute introduces tight coupling between
the importer and the exporter, as you force the framework to wire you to a particular
bundle. This may indicate the two bundles should be merged. The
type
attribute you
made up is a little more flexible, but still adds a degree of coupling. If you imagine a
grand scale of coupling, this is much closer to an import without attributes than it is to
the import with the
bundle-symbolicname
import. In either case, you're constraining
the framework resolver, which can introduce other problems. Depending on how the
rest of the bundles in the runtime are wired together, it may not be possible for the
importer to resolve, even if the right version of the
fancyfoods.split
package is pres-
ent in the runtime. This can happen when the bundle importing the split package
needs to import a different package from another bundle that has wired to the
wrong
version of the
fancyfoods.split
package.
Attributes have another critical limitation when it comes to split packages: they
allow you to choose one export or the other, but never both. If the importer needs
classes from more than one part of the split package (packages can be split across as
many bundles as there are classes in the package), then they're out of luck.
OSG
i does offer a workaround for the split package problem that prevents the
importing bundle from having to do anything messy, and that allows the importer to
see the union of two or more parts of the split package. This requires one of the export-
ing bundles to use the
Require-Bundle
header to require the bundle that exports the
other part of the split package.
Require-Bundle
is a bit like
Import-Package:
, except
