Twitter github

Third Party Bundle Hell?

I recently blogged about how to deal with third party dependencies in an OSGi-based environment and a thought came across my mind about putting ourselves in a crappy situation. What do I mean? Well, let me illustrate with a simple example using the Apache Commons Discovery library. In the Spring Repository we see this:


...
Bundle-SymbolicName: com.springsource.org.apache.commons.discovery
Import-Package: org.apache.commons.logging;version="[1.1.1, 2.0.0)"
...

In the Eclipse Orbit repository:


...
Bundle-SymbolicName: org.apache.commons.discovery
Require-Bundle: org.apache.commons.logging;bundle-version="[1.0.4,2.0.0)", org.junit;bundle-version="[3.8.0,4.0.0)";resolution:=optional
...

I wonder what we’ll see when Apache decides to start offering bundles as a download option… the point here is that we are in a precarious position with third party libraries. Each bundle repository will have its own format when it comes to things… they may conflict or they may not. For example, the current example conflicts because of the choice of using Require-Bundle versus Import-Package as the way to express dependency information. The problem could be fixed if Orbit switched to using Import-Package but this still doesn’t help people who are using Require-Bundle as a client of these libraries.

It seems we may need some set of best practices that bundle repositories follow that ensure bundles from each repository are interoperable. What are people’s thoughts on this topic? Have you been bitten with interoperability issues by using bundles from different repositories? I only see this problem becoming more annoying as more people start adopting OSGi.