DataNucleus JIRA is now in read-only mode. Raise any new issues in GitHub against the plugin that it applies to. DataNucleus JIRA will remain for the foreseeable future but will eventually be discontinued
Issue Details (XML | Word | Printable)

Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Unassigned
Reporter: Matthew T. Adams
Votes: 0
Watchers: 1

If you were logged in you would be able to see more operations.
DataNucleus AccessPlatform

Remove Require-Bundle OSGi header and auto-generate MANIFEST.MF using mvn "bundle"

Created: 05/Oct/11 04:50 PM   Updated: 17/Dec/13 06:18 AM   Resolved: 15/Dec/13 07:24 PM
Component/s: None
Affects Version/s: 3.0.0.release, 3.0.1, 3.0.2
Fix Version/s: 3.3.6

Severity: Development

 Description  « Hide
According to the OSGi r4 spec, "Require-Bundle" is a bad word. See section 3.13.3 of the OSGi spec at

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
Import-Package: q
B: Export-Package: q
C: Export-Package: q
D: Require-Bundle: B, C
Import-Package: p
[figure omitted]
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.)

Andy Jefferson made changes - 05/Oct/11 05:10 PM
Field Original Value New Value
Affects Version/s 3.0.3 [ 11344 ]
Andy Jefferson made changes - 13/Dec/13 03:48 PM
Summary Remove Require-Bundle OSGi header Remove Require-Bundle OSGi header and auto-generate MANIFEST.MF using mvn "bundle"
Andy Jefferson made changes - 14/Dec/13 02:59 PM
Fix Version/s 3.3.6 [ 12064 ]
Andy Jefferson added a comment - 15/Dec/13 07:24 PM
GitHub master uses mvn bundle (with all of its version naffness and subsequent overrides) for all DN plugins that need it

Andy Jefferson made changes - 15/Dec/13 07:24 PM
Status Open [ 1 ] Resolved [ 5 ]
Resolution Fixed [ 1 ]
Andy Jefferson made changes - 17/Dec/13 06:18 AM
Status Resolved [ 5 ] Closed [ 6 ]