OSGi Players To Watch

Any veteran developer knows that integration and maintenence is where all the time and money goes, writing a simple module can be a few days work once the requirements and interfaces are set in stone. Modularity (OSGi) promises to eliminate much of that cost, by never fully integrating a module into the rest of the code base. Every module stands on its own, lives in its own classpath, and develops in its own tested, versioned process.

When things change in the modular world, you snap in a different version of the binary with its [possibly] different interface, and there is never any jar or binary hell. That's the promise, anyway.

What if you've bought into this idea of modularity and are ready to try it? 

Not so fast.  

Before you jump, you need to ask yourself if the tooling is ready for your team's big move.

You're a real team. It's not just OSGi, you also use other mainstream infrastructure for efficienty, such as Maven and Eclipse and Spring and JUnit and Hudson, and you're not about to give that up just for an illusive promise of efficiency from modularity. 

Is OSGi ready yet? 

In a word, "almost". Wait two years, and it may still be "almost". The problem is not foundational, OSGi is 10 years mature. The problem is tooling.

So here is a recap of some of the work that is going on, for those of you that want my very biased perspective. WARNING: Nothing written below is empirically correct or peer reviewed. I've done a kind of best effort, I'll leave the comments sections below for collecting the various rebuttals and further information. 

SpringSource and OSGi

Only the Eclipse Foundation itself has done more than SpringSource in moving OSGi to the "last mile" within corporate development teams. Interestingly SpringSource has spent most of the past year moving what were previously it's own projects into the Eclipse Foundation fold.

Spring OSGi generally becomes Eclipse's Gemini, and also I believe a reference implementation of the OSGi's own Blueprints specification.

DM Server becomes Eclipse's Virgo project. 

Both of these projects are moving along well, though the last couple years hasn't seen much of anything settle into a strong, documented, well used production tool. If progress seems glacial, compare that to none at all, because that is the alternative if SpringSource wasn't funding this work. 

STS, Spring Tool Suite, is doing a lot of great work with OSGi also, most notably it's integration with DMServer and Spring OSGi, and it's Bundlor tool for automating the arduous task of generating proper MANIFEST.MF files. 

The problem with STS is it's glacial progress in this area. Great stuff, just hasn't moved very far in the last couple years.

Sonatype(Maven) and OSGi

Sonatype has embraced OSGi full bore in a kind of funny roundabout way, primarily because it got interested in tooling up it's m2eclipse team with a maven build. Since m2eclipse is an Eclipse product, that means it's an OSGi product.

Sonatype has funded a very active project named Tycho which is working on a maven build for Eclipse plugins. Sonatype not apologetic about it's undocumented pre-1.0 state, nor should they be. It's a huge effort, lots of Eclipse development teams are already using it, and Sonatype deserves nothing but praise and gratitude for it's great work in this area.

The biggest problem with Tycho is that it's not yet a generic OSGi tool set, it's more geared towards Eclipse development teams. That's too bad for the short term, because the promise of OSGi won't be realized until it moves beyond Eclipse development.

It also appears less likely that Tycho will do a corporate development group much good without a Nexus Pro license. Maybe that's not a bad thing, too early to evaluate.

Eclipse Foundation and OSGi

Eclipse as been based on OSGi for many years now. For most of us, Eclipse development is the gold standard in OSGi tooling. 

Oddly enough, it's early success with OSGi is Eclipse's biggest problem for the rest of us, because Eclipse is NOT designed as generic Java tooling. It is Eclipse Plugin tooling. They never intended for it to be a generic OSGi toolset It's a good problem to have, but it comes with it's own set of challenges if you're developing binaries designed to work in non-eclipse environments, especially without a Maven build and a more generic implementation of IOC such as Spring or Guice or the one that comes with Java.

Keep an eye on this space especially, it may change nicely next summer with the next version of Eclipse.

IBM and OSGi

IBM funds Eclipse, so you can't say that it isn't interested in OSGi, since Eclipse is the OSGi Gold Standard.

Beyond that, it is really hard to detect any top down efforts at bringing OSGi fully into the IBM playbook, the way it did with Linux years ago. Maybe I'm just not reading the right stuff.

Oracle and OSGi

Sun, now Oracle had interests in their own version of non-OSGi modularity now featured in Netbeans. Even more to the point, they have been very late in coming to the party. For a long time, Sun even had it's own JSR as a competitor to OSGi, which I hope is finally dead.

Even if Oracle had a top down dedication to OSGi it would take years to fully implement, but without such direction, it seems improbable that it's many separate groups will get their act together in this important area, at least any time soon. 

If any vendor suffers a technical debt from a lack of modularity within the JVM, I can think of no one more obvious than Oracle's own vast array of tooling. Why they haven't embraced OSGi as an easy way to eliminate their own crazy mash-up of tooling is something I don't get. No one could benefit more.

Whether advocating, tooling for, or even just consuming OSGi within their own products, Oracle has been almost missing-in-action. Please advise if you see where I may be wrong on this. And no, I don't count the heroes at Glassfish as critical mass in this area, nor the brilliant guys at Netbeans, both of which are doing some pretty impressive work with OSGi.

HP and OSGi

I've seen nothing so far that indicates any major push within HP to reap the benefits of modularity or OSGi from a top down perspective.

Please advise if you have information to the contrary.

PAX (Toni Menzel) and OSGi

Who is this guy? One of the most interesting and helpful players in the OSGi space is Toni Menzel, with the set of PAX tools for OSGi testing, running, and development. 

Like no other person or entity, Toni is focused on providing generic tools for OSGi that run and test across tool sets. It even works for me, at times. Pax Exam, Pax Runner, Pax Construct, too many cool OSGi toolsets to mention here, and a number of folks jumping in with Toni too.

Somebody needs to fund this fellow, he's doing the cross platform work that makes everything else that anyone is doing within specific platforms more valuable. Go Toni!

Many Many Smaller Players and OSGi

There are so many players - from Apache Felix to Concierge to Knopflerfish to many other servers, containers, tool sets, too many to mention here.

Bottom Line: Wait For Someone Else To Move First

If you're well funded and can dedicate a full time person on your team to straighten out all the kinks, OSGi may be an option for your development group, even today. Just budget plenty of time/money, you'll need it.

If on the other hand you like to cheat, wait for the 10 minute Eclipse tooling version to come out and make it all easy for you from head to stern and across toolsets, my guess is that 2010 is not your year, and I doubt it's 2011 either.

Until the big players really start doing this for their own stuff (Read: Oracle, SpringSource, IBM) it's probably not going to be easy for the rest of us, tooling wise.

Your Corrections Here:

This is an area which deserves a lot more discussion than it gets, maybe not here, but somewhere.

For too long, developers have been held back by the stupid burden of integrating their small perfected modules into stupid big ball of mud apps. That burden is not necessary, and counter productive. With OSGi, it doesn't have to happen.

From http://appwriter.com/osgi-players-watch