Spring/OSGi integration reaches first milestone

So, one of the projects I’ve been working on has been the integration of Spring and OSGi. This has been the first real open source project I’ve been involved in and it’s been a very good experience. The team is small and everyone is smarter than I am, so that’s always a pleasant experience.
The project reached its first milestone release yesterday. I have to say that this is one of the finest pieces of code I’ve ever worked on. The system we released, while incomplete, is quite solid in what it does implement. Most of the features are there, though, and we’re using the Spring/OSGi integration internally on our own projects here at House Harkonnen.
Costin, the young buck from I21 who’s been doing a lot of excellent work, has a blog entry on the Spring/OSGi integration over at the I21 blog, providing an excellent overview of what we’ve accomplished.
One of the features I’ve been making a lot of use of is the whole JUnit integration. Early on, it became quite clear that it would be a monumental task to mock up an entire OSGi environment. Worse, because we wanted to support three OSGi containers (Equinox, Knopflerfish and Felix), it also became crystal clear that it would be a galactic size task to replicate all the quirks of these containers in a mock environment. So Costin really grabbed the bull by the horns and created one honey of a integrated testing framework for in situ OSGi unit testing. Really, you have to play with it to really understand how very cool it is.
Basically, the issue with any in-container testing is getting your unit test to run inside the container. This requires setting up and starting the container, of course, deploying your test code (in the OSGi container case, the bundles you need for your test scenario) and then there’s the JUnit test itself. Now you have to remotely trigger the running of the test and somehow get the results back from the test run.
Costin’s framework does all this with a very slick framework which sets up and runs the OSGi container in the same process, wrapping your JUnit test class within an automagically generated OSGi bundle. The end result is that you now have in-container testing which can be run as any JUnit test is run – from Ant or from Maven, or from within your favorite IDE. As I said, this is very cool and you have to actually play with it to believe it. There’s nothing even approaching it for any other container.
So, what’s most excellent about this is that I can now structure my build to test the actual services and frameworks with simple mocks, outside of the OSGi environment, due to all the features we all know and love from Spring – i.e. we use Spring to create and configure the services that the bundle contains. Then I can have another Maven module which takes the bundle – which at this point is known to be pretty well functioning – and perform further testing in the OSGi container. As there are things that are simply impractical to mock outside of the OSGi container, such as class loading and dynamic services and events, this results in a system which has been battle hardened right in your build. By the time you actually deploy the code in anger for functional testing, the system has a far greater probability of correct operation. As I said: quite cool.
Anyways, give Costin’s blog entry a read. You can download the Spring/OSGi M1 release, and you should visit the official Spring/OSGi integration project site as well.
Enjoy.