According to the OSGi r4 spec, "Require-Bundle" is a bad word. See section 3.13.3 of the OSGi spec at http://www.osgi.org/Download/Release4V43
Bottom line, as I understand it: you should not be requiring bundles, but instead importing packages. With Require-Bundle, you are unnecessarily binding yourself to a bundle, which may change over time. What you really depend on in OSGi are packages. Their argument is that the use of Require-Bundle introduces unnecessary coupling.
From the spec:
3.13.3 Issues With Requiring Bundles
The preferred way of wiring bundles is to use the Import-Package and Export-Package headers
because they couple the importer and exporter to a much lesser extent. Bundles can be refactored to
have a different package composition without causing other bundles to fail.
The Require-Bundle header provides a way for a bundle to bind to all the exports of another bundle,
regardless of what those exports are. Though this can seem convenient at first, it has a number of
• Split Packages - Classes from the same package can come from different bundles with Require
bundle, such a package is called a split package. Split packages have the following drawbacks:
• Completeness - Split packages are open ended, it is difficult to guarantee that all the intended
pieces of a split package have actually been included.
• Ordering - If the same classes are present in more than one required bundle, then the ordering
of Require-Bundle is significant. A wrong ordering can cause hard to trace errors, similar to the
traditional class path model of Java.
• Performance - A class must be searched in all providers when packages are split. This potentially
increases the number of times that a ClassNotFoundException must be thrown which
can potentially introduce a significant overhead.
• Confusing - It is easy to find a setup where there is lots of potential for confusion. For example,
the following setup is non-intuitive.
A: Export-Package: p;uses:=q
B: Export-Package: q
C: Export-Package: q
D: Require-Bundle: B, C
In this example, bundle D merges the split package q from bundles B and bundle C, however,
importing package p from bundle A puts a uses constraint on package p for package q. This
implies that bundle D can see the valid package q from bundle B but also the invalid package q
from bundle C. This wiring is allowed because in almost all cases there will be no problem. However,
the consistency can be violated in the rare case when package C.q contains classes that are
also in package B.q.
• Mutable Exports - The feature of visibility:=reexport that the export signature of the requiring
bundle can unexpectedly change depending on the export signature of the required bundle.
• Shadowing - The classes in the requiring bundle that are shadowed by those in a required bundle
depend on the export signature of the required bundle and the classes the required bundle contains.
(By contrast, Import-Package, except with resolution:=optional, shadows whole packages
regardless of the exporter.)