Why don't repositories in the bnd workspace model support transitive dependencies?

Question

According to the Introduction to the bnd workspace model the repositories define and exact set of dependencies and not support transitive dependencies because they tend to make horrible OSGi systems.

Can someone provide a more detailed explanation (using concrete use cases is highly appreciated) when that is true? I guess this mainly related to the correct Import-Package list in the manifest. How transitive dependencies should be handled? Is there a way to provide all required imports?

Does that mean maven-only bundle development (with bnd-maven-plugin or maven-bundle-plugin) is more likely to be error-prone since maven does support transitive dependencies? How transitive dependencies should be handled in this case?

Thank you!

Answer 1

In OSGi bundle creation and application assembly are two very different things. When creating bundles with maven you of course use transitive dependencies. The result oft the maven-bundle-plugin or bnd-maven-plugin is entries in the jar Manifest. They define things like imported or exported packages. This result does not contain transitive dependencies. These bundles can be used in workspace model as well as maven model.

The application assembly is a different process. There you build a so balled repository which is a list of possible bundles to install. In the workspace model you list each bundle without transitive dependencies. In the maven based application assembly you define the repository using the dependencies of a pom. There the transitive dependencies are used.

The reason why transitive dependencies are not always good is that the dependencies of a bundle are often not the dependencies you want to use in your application. So the maven model has the potential of adding problematic bundles to the repository. These dependencies might then slow down to resolution of the actual bundles to use or even result in non working resolved bundles. Luckily you can fix this by excluding some of the transitive dependencies using the usual maven excludes.

In my personal experience transitive bundles are often very useful for application assembly as you do not have to list all dependencies by hand. The problematic cases are not quite easdy to fix. So I do not agree that transitive dependencies should not be leveraged.

Answer 2

The primary reason is that OSGi is a specification for a reusable component system. If you try to do that with transitive dependencies, you'll find you run into problems at assembly time:

• version conflicts – Component A uses version 1 of X, component B uses version 2 of X. These conflicts are often tapered over in transitive systems like Maven but time bombs are lurking to go off.
• environment dependencies – Some components depend on Windows, other on Linux. Very hard to reconcile these differences.
• version compatibility – Often components could be working together but their transitive dependencies make it impossible.

To address this problem, OSGi invented the service model. The service model allows a component to depend on an API. Once you depend on an API, you no longer have transitive dependencies since transitive dependencies are almost all about implementation dependencies. There is, of course, a dependency on the API, but that has become fuzzier since it is both the consumer of the API and the provider of the API depend on this. This fundamentally changes the dependency model for the better, but very few people grasp this.

I.e. in the service model, the buck stops at the service API. You compile against the API and you can write a lot of test cases against the API. However, your component should never depend on a specific implementation. The first time your component sees an implementation should be in a runtime.

Of course, this forfeits some convenience at the early stages of development. Where in a transitive model, like Maven, things are supposed to compile out of the box, in bnd you need to think about your, and your component's, dependencies ahead of time. This is inconvenient and annoys Maven users, but it is a requirement to make components reusable in very different environments. Maven tends to lock the runtime in often incompatible configurations, in OSGi you do not want the runtime to have any unnecessary restrictions to maximize the reusability of your components.

Putting this restriction on developers, no implementation dependencies, is often too much for developers used to the short term convenience of transitive dependencies. However, developers that embrace this model quickly see that it opens up a vista of possibilities later in the development cycle and reduces a significant of maintenance. Even I am sometimes tempted to skip this level of indirection but somehow, at even slight complexity, I revert because the model has so many advantages on the macro level.

I've been involved in many complex systems and in virtually all cases a lot of complexity in disappears when you kill the transitive dependency sirens.