Tales from the OSGi trenches

My Tales from the OSGi trenches presentation today at ApacheCon went well, timing was surprisingly good given that I gave this talk for the first time.

People can certainly relate to the issues that we’ve been facing with OSGi, and the realization is that the large majority of them can be linked to lack of developer education and lack of documentation and examples.

Things will get better, but my conclusions page already has a lot more smileys than monsters!

8 Responses to Tales from the OSGi trenches

  1. Steven Noels says:

    Hi Bertrand, nice overview. When starting Kauri, we un-decided for OSGI and went mostly our own road (heh, go figure), which resulted in the Kauri runtime and some other core Kauri concepts like modules and jars. I see many parallels with your view on OSGI however, and I see we address some missing stuff as well, like deployment for instance.




  2. bdelacretaz says:

    Thanks Steven, good to hear from you!

    I’ll have a look at that Kauri stuff – coming from you guys it has to be good!

  3. Clement says:

    Hi Bertrand,

    Nice presentation. It’s really interesting to get such kind of feedbacks.
    Here are some comments:
    – First of all, when you talk about skills, it is not only skills. OSGi offers a new way to think/design applications. However, this is quite different of the “regular” way. It’s somewhere between component model, product lines, and service oriented computing (I voluntary not use the SOA term, that, in my opinion, is misleading). So, when designing an OSGi application, you have to think about how all the “pieces” collaborate together. It’s no more a monolithic app but now it’s a jigsaw! And not any jigsaw, a dynamic jigsaw! So, in fact OSGi skill is one thing, OSGi way of thinking is a plus. More specially, you mention startup issue. This is a well-known problem in OSGi when using service-based interactions. In fact, every parts of your application have to know what has to be done if required services are not there… Easy to say, not easy to do. Moreover, in general, OSGi application development requires a good understanding of the concurrency / threading issues.
    – Tools, for sure need to be improved… But as the application is not designed/built and executed in the same way that regular applications, it makes sense that the same tools doesn’t work very well. I’m looking forward the OSGi tooling summit (today). Today, we finally have enough experience (success but failureS) in OSGi development to understand what kinds of tools are needed.
    – About tooling, I will just detail one step: testing and specially in-container tests. If we avoid the traditional debates about unitary vs integration vs acceptance tests, let’s define this as a way to test your bundle/service in a “true” OSGi container. In fact, what we would like is just an easy and integrated (in the build process) way to execute tests in OSGi. Today, we have several alternatives. junit4osgi is one of them (subproject of Apache Felix). It is a very simple framework: develop your test, create a bundle with them, and it will execute your test automatically during the maven integration-test phase in an embedded OSGi framework. A lot of works need to be done before getting a perfect framework to test OSGi application. But, it seems that this small project has some adepts… If you have ideas about how to improve it, it is welcome!


  4. Thanks Clément, and it was great meeting you at ApacheCon!

    Agree about the “OSGi way of thinking”, you’re right that it’s not just raw skills that are needed.

    I’ll have a look at junit4osgi, that looks very interesting!

  5. Luke Patterson says:


    Nice presentation. I just ran across it today. I was especially interested in the testing portion. Do you think it would be helpful if JUnit itself was OSGi-ified? I recently logged a feature request [1] with JUnit regarding OSGI-ification.



    [1] http://sourceforge.net/tracker/?func=detail&atid=365278&aid=2720888&group_id=15278
    [2] other recent discussion http://www.nabble.com/Re%3A-maven—osgi—repositories-p22770424.html

  6. bdelacretaz says:

    @Luke, one of the things that I’d like to try at some point is to run in-system tests, for example by including JUnit tests in bundle jars, and providing a console to run those tests.

    OSGified JUnit jars would be needed to implement that. I’m not sure when I’ll have time to implement this, so don’t have an urgent need at the moment.

  7. Clement says:


    Junit in OSGi is exactly the purpose of junit4OSGi :-). It provide a junit runner running test inside OSGi:



%d bloggers like this: