What is the best way of grouping OSGi bundles to make a coherent 'application'

Question

The "OSGi way" is to develop separate bundles containing discrete, coherent pieces of functionality. Sometimes these bundles contain utility classes, sometimes they depend on utility classes and set up their own OSGi Services.

Users, on the other hand, are unlikely to be exposed to bundles. They care more about the application, a piece of software that performs a task or solves their problem. Normally an application will use multiple bundles (say, imported via Import-Package) to perform its tasks.

What is the best way to formalise this relationship in the OSGi world? One example requirement would be something as simple as showing the current version number of the application (not the bundle(s)) to to the user. How would this version number be discovered?

Eclipse has a concept called 'features' but this is not OSGi standard.

Peter Kriens has written about OSGi applications and his article makes sense. My take away from it was that an application can map to a bundle; it's just that the bundle uses other bundles in some way. But if one is to create an application bundle using Import-Package, I don't see how that can be feasible from a development point of view.

One way may be to have an 'application bundle' that uses Require-Bundle and has its own version, but Require-Bundle is frowned up in the OSGi world.

Using Import-Package to import all the required packages with the required versions, however, adds a significant maintenance overhead to the developer to the extent that I don't think it's feasible. Each time the smallest change is made, even to an implementation package, the package version must be updated, and then the dependency on the package version updated in the 'application bundle'.

Answer 1

The framework is the application ... The biggest mistake imho in the OSGi world is to see OSGi as a multi-tenant framework, it was not designed for that purpose and it is not a good fit. Inside a framework, there is high cohesion, all services registered are your services. The architectural model of OSGi allows you to write applications from loosely coupled components wired through services. Which is imho by far the best it gets in software (though there are lots of missing components unfortunately, will come).

In bndtools we go out of our way to help with this model. A bndtools bndrun file is basically an application that you can deploy. bnd can turn this bndrun file into runnable Jar with a Main-Class manifest header. (And with JPM it will be easy to deploy on any system.)

So the workflow is basically: design your services (== architecture), find standard components, develop missing components, test the components, test the integration, and turn the whole thing into a runnable JAR (or WAR).

Obviously you can still run multiple frameworks inside a single VM if so desired, but never run different unrelated applications in the same framework, not a good idea, life is hard enough as it is.

Answer 2

I think the word you're looking for is 'subsystem', I think there is an OSGi draft spec. out there.

My personal view:

Build your bundles and store them somewhere (For example a Sonatype Nexus server, I'm pretty pleased with it, it even has support for OBR and a limited support for generating p2 data)

An 'application' is then a selection of bundles with a certain version out of that repository, which you can version again.

There is no real standard yet, I think at this point you'll need to pick one of the non standard ones out there. The cost of changing to the standard one or even support multiple ones shouldn't be all that great.

These slides mention all of them

Answer 3

If you use a resolver such as OBR or the new R5 resolver then using Import-Package does not necessarily create a large maintenance overhead.

However, the Require-Bundle way is also possible. An "application" typically consists of a small number (say, 1-5) "interesting" bundles. Then there are all the rest such as dependencies, SCR, Blueprint, etc. You could therefore create a single top-level Application bundle that uses Require-Bundle to refer to the small set of interesting bundles, and then all other dependencies are specified with Import-Package.