tags:

views:

301

answers:

3

OSGi allows for dependencies to be determined via Import-Package, which just wires up a single package (exported from any bundle), and Require-Bundle, which wires up to a specific named bundle's exports.

In building a greenfield OSGi application, which approach should I use to represent dependencies? Most of the bundles will be internal, but there will be some dependencies on external (open-source) bundles.

A: 

I think you should use Import-Package if you have no concerns about versioning, as this will find the right bundle (and it's theoretically easier) However, if you want to control the versioning, then you should use Require-Bundle. My preference is Require-Bundle, it gives good control, and I don't care about the functionality of having OSGi figure out which package is in which bundle. Also, there is the issue of a package that might be in multiple bundles. I don't know how this case is handled with Import-Package. It works fine of course with Require-Bundle.

Francis Upton
A: 

I believe Import-Package gives you looser coupling and should be preferred. I use it when declaring dependencies on packages that I don't own, such as slf4j, and I can swap implementations as I wish. I use Require-Bundle when the dependency is something I have control over, such as my own bundles, because any important change would have gone through myself anyway.

omerkudat
+2  A: 

I believe Require-Bundle is an Eclipse thing (that has now made it in the OSGi spec to accommodate Eclipse). The "pure" OSGi way is to use Import-Package, as it specifically decouples the package from the bundle that provides it. You should be declaring dependencies on functionality that you need (the Java API provided by a certain version of a certain package) instead of where that functionality is coming from (which should not matter to you). This keeps the composition of bundles more flexible.

JavaScript analogy: This is like detecting whether a web browser supports a certain API versus inferring from what the user-agent string says what kind of browser it is.

Peter Kriens of the OSGi Alliance has more to say about this on the OSGi blog.

Probably the only case where you need to use Require-Bundle is if you have split packages, that is a package that is spread across multiple bundles. Split packages are of course highly discouraged.

Thilo
Both Require-Bundle and Import-Package are defined in the OSGi spec; there's no "pure" variant of the two.
AlBlue
@AlBlue: updated my answer to make it more clear that while Require-Bundle is in the spec, it is only made it there for Eclipse compatibility.
Thilo
I think Thilo is right. As Peter Kriens mentioned in the article: "Require-Bundle has an intuitive appeal that is hard to deny." But it is unnecessarily tying the bundles together.In Java world I would compare it to IoC vs looking up dependencies directly.One example is depending on `commons-logging` bundle vs depending on `commons-logging` API package. In the latter case you can easily swap the `common-logging` bundle with appropriate SLF4J adapter bundle that also exports the `commons-logging` API package and thus seamlessly creates a bridge from `commons-logging` to SLF4J.
Pavol Juhos
+1 because this is a good discussion of this topic. Small addition: require-bundle could be used to express dependencies that are different from just packages, e.g. a Bundle requires a resource in the form of another bundle to be present.
akr
Just to make an observation - the 'Require bundle has made it to the OSGi spec to accommodate Eclipse' is factually incorrect. It was added in OSGi 4, but most of Eclipse Import-Package. Eclipse 3.0 switched over to using OSGi in June 2004; OSGi 4 (with Require-Bundle) was released in August 2005.
AlBlue