Delving deeper into modularity - OSGi in Action - page 174

Now, if you have another bundle that wants to use the entire org.foo.bar package, it
has to require both bundles. The bundle metadata may look something like this:

Bundle-ManifestVersion: 2
Bundle-SymbolicName: C
Bundle-Version: 1.0.0
Require-Bundle: A; version="[2.0.0,2.1.0)", B; version="[2.0.0,2.1.0)"
When code from bundle C attempts to load a class from the org.foo.bar package, it
follows these steps:

It delegates to bundle A. If the request succeeds, the class is returned; but if it
fails, the code goes to the next step.

1

It delegates to bundle B. If the request succeeds, the class is returned; but if it
fails, the code goes to the next step.

2

It tries to load the class from bundle C's local class path.

3

The last step allows org.foo.bar to be split across the required bundles as well as the
requiring bundle. Because searching continues across all required bundles, bundle C
is able to use the whole package.
What about a bundle wanting to use only one half of the package? Instead of
requiring both bundles, it can require just the bundle containing the portion it needs.
Sounds reasonable; but does this mean that after you split a package, you're stuck with
using bundle-level dependencies and can no longer use package-level dependencies?
No, it doesn't, but it does require some best practice recommendations.

HANDLING SPLIT PACKAGES WITH IMPORT-PACKAGE
If another bundle wants to use Import-Package to access the portion of the package
contained in bundle B, it can do something like this:

Import-Package: org.foo.bar; version="2.0.0"; bundle-symbolic-name="B"
This is similar to using Require-Bundle for the specific bundle. If you add an arbitrary
attribute to each exported split package—called split , for example—you can use it
to indicate a part name instead. Assume you set split equal to part1 for bundle A
and part2 for bundle B. You can import the portion from B as follows:

Import-Package: org.foo.bar; version="2.0.0"; split="part2"
This has the benefit of being a little more flexible, because if you later change which
bundle contains which portion of the split package, it won't break existing clients.
What about existing clients that were using Import-Package to access the entire
org.foo.bar package? Is it still possible? It's likely that existing client bundles are
doing the following:

Import-Package: org.foo.bar; version="2.0.0"
Will they see the entire package if it's now split across multiple bundles? No. How can
the framework resolve this dependency? The framework has no understanding of split
packages as far as dependency resolution is concerned. If bundles A and B are