What is a typical OSGi life-cycle?

Question

I would like to gain some insight into the life cycle that is used in industry when developing and deploying OSGi based systems.
My main focus is on the deployment phases, after the development phase has created versioned and packaged a bundle. Specifically testing procedures that may be carried out, and method of integration.
A very high level account with some low level details would be very helpful.
Thank you.

Answer 1

You could study Eclipse, as it is one of the largest OSGi based systems I am aware of. And they have many documents that talk about versioning and how they use testing in the eclipse platform.

Answer 2

I recommend reading the Getting Started Guide for dmServer or look at other information from the SpringSource.org dmServer site.

The Getting Started Guide writes about a small web application called GreenPages, which is built up in stages from a skeleton project structure. The final implementation is a modular, multi-bundle application. Along the way, unit and integration testing is demonstrated in Eclipse, as well as standalone (Maven) build.

Although Eclipse is large, and a useful example to look at, I would not expect it to be typical of OSGi modular systems, nor am I aware of an explanation of the development process life-cycle employed.

Answer 3

OSGi bundles can be assembled together in a running OSGi engine (whether Equinox, Felix, dmServer etc.). As with other code, there may be dependencies on platform-specific behaviour (such as code only working on Windows that uses c:\ style file references), code that works together with JNI and is only valid for x86 platforms and so on. OSGi doesn't help or hinder software testing in these cases.

Where it can add complexity is in the sheer combinatorial explosion of running bundles. Unlike a Java application, which can quite happily run on a single monolithic CLASSPATH, you tend not to find errors until later on (like the ClassNotFoundException when trying to load a JDBC driver, for example). OSGi helps somewhat in this regard in ensuring that you must at least have requisite package exports for bundles; but even then, some packages can be optional and therefore end up with the same problem.

As an OSGi bundler, you really need to test:

• Do these bundles actually all start, i.e. after installing into your favourite OSGi engine, does start n work properly? If you've got all of your dependencies, then it should go from INSTALLED to RESOLVED to ACTIVE; if it stays around in INSTALLED then it means it's missing some dependencies
• Does your application need certain bundles (like Declarative Services or Remote Services) started up when the OSGi VM starts?
• Are there start-order issues between bundles? They should all Just Work but you may want to test what happens if Bundle A starts before Bundle B

Those are the kind of additional things you'd have to look at testing when certifying a set of bundles to work with each other. Ideally, you'd have in-OSGi VM tests you could run - that's how Eclipse's JUnit plugin tests are run.