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

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.