If you use OSGi in order to make your application dynamic, then your tests should test the dynamicity aspect of your application, otherwise how would you know whether your application behaves dynamically or not? how would you be sure that clients use the service with highest rank when such is registered? that bundle updates wouldn't break the application? or that any other risks you have when working on dynamic OSGi-based applications are tested and verified properly? Surely, you wouldn't want to verify this behavior in production systems or manually. Agreeing on the importance of dynamicity tests, we will move to the next issue that developers of dynamic OSGi-based applications have, how to test dynamicity?

I'm glad to announce that DynamicJava.org finally has a maven repository where the artifacts of our projects are hosted. So far, I was able to place there only the latest releases of DynamicJava.org projects, but with time other popular OSGi-related projects and core OSGi artifacts will be placed to make it easier for developers (I'm one of them, by the way) who spend much time looking for un-hosted important OSGi-related Maven artifacts. Also, if you have an OSGi-related Maven artifact, you are welcomed to host it here. The URL of the repository is http://maven.dynamicjava.org/ - Can't have enough of looking at this URL :) looks beautiful and simple to remind, wish the URLs of all maven repositories look the same.

It's worth to mention that I used Nexus, which is an open source Maven Repository Manager. The user interface is simple yet powerful and the application had scripts which could install and run it on 9 operating systems (excellent feature for a Linux dummy like myself). Kudos for the guys who developed it, it would have been great even if only 10% of the projects in Java space were as simple and accurate as this one.

Integration Scenarios

Taking into account that Esper supports runtime changes, the main challenge that is left for OSGi developers who want to use Esper in the OSGi Environment is deciding upon the optimal design for Esper-OSGi application to make it modular and dynamic so you could deliver features in bundles at runtime. Depending on the usage scenario, you might have additional requirements, like making the Event Model extensible at runtime. I tried three different variants, each of them had advantages and liabilities, below is a small discussion on each of them:

Observing different efforts in the OSGi space I noticed a camp of developers who believe that the whole OSGi Concept shouldn't conflict much with past or simply not-osgi efforts so it wouldn't require from developers any OSGi-specific efforts to run their application inside the OSGi Environment, with this approach developers could run their OSGi-oblivious applications in the OSGi Environment and still be able to evolve them to benefit from OSGi in the future depending on their needs.

If you followed my previous work on tackling OSGi-incompatible applications you might share me the view that all of the problems that OSGi-incompliant and OSGi-incompatible applications have when running them in the OSGi Environment are either caused by wrong metadata or class/resource loading problems. Not that I'm passionate about the idea above, but having Bundler on one hand (which I consider to be by far the most powerful and advanced solution for dealing with OSGi-incompliant libraries) and ClassLoading-Utils on the other I came to know that it doesn't require much from me to enable this concept, I also decided to go one step further so I would allow absolutely any standalone Java Application run normally in the OSGi Environment, this led me to add a new feature to Bundler that allows users to instruct Bundler to generate a Bundle Activator for JAR archives which contain a Main Class with main method so when the generated bundle is started the Activator will invoke the main method.