Where Does OSGI fit into Your Daily Routine?

This blog assumes you are already a fan of loose coupling and high cohesion in your coding practices. If not, you may need help, but this article won't be the help you need.

Before you judge whether OSGI fits into what you do,

you really need to think about the specifics of your environment. The article linked here (see the graph especially) clarifies some of the thinking about hitting the right inflection point before you think about OSGI.

Do These Things First:

There are many things that are much more important than OSGI. Here's one perspective based on my experience.

A fantastically successful enterprise java project in 2009 was only possible because my team quit working on infrastructure and used tools that really really worked well together - without a lot of fuss.

No fuss, no muss, no bother. Mind you these were NOT chosen because they are, or are not, best of breed - that wasn't the point. Rather, each is way good enough. Main thing is they are all very commonly used, and thus work very well together.

Next: Technologies Left Behind

Personal favorites were left behind, only because it was a drop dead tight schedule where every minute counted. Though time was a excuse, it may not have worked, these might have actually sped up the project if we had picked them up at exactly the right inflection point. Even this past year, might have really helped.

The question here is OSGI. When should I bring it in relative to these other three? That's an easy one, the others come first, and in the above order.

It is only because I have bought some time by using small projects and linked dependencies - see below - that there is more low hanging fruit for me in TDD and Groovy. Externalizing rules is more about the kind of projects I am doing.

Even if I had the other three already in and set, would it be time yet?

OSGI - What price am I currently paying to not have it?

Here is what I would have to do anyway, to make OSGI helpful:

Projects in our repository are already extremely granular. We ended up with about 30 projects for a single enterprise application.

  • Projects, not just packages - to build separate components
  • Maven dependencies between them, to keep things as loosely coupled as possible.

Splitting code up into these little project components has allowed us to keep each project incredibly focused and clean, at least at that coding level. Is that really helpful? We found that small, singularly focused projects (components) allow us to work with speed and dispatch. Really did make a big difference.

The advantage disappears to nothing, though, at runtime, because everything gets put in one big ball of mud, at deployment. Other than keeping it organized, we didn't pay too high a price for this. It was just a bit gangly and time consuming, keeping all the dependencies organized.

You would then correctly conclude that we got the benefits of loose coupling only in the focus of the developers. For real decoupling, nada. Is that important? The answer for me is easy - I want both, but only if I can afford it, time wise.

When Does OSGI Hit The Inflection Point?

OSGI hits the inflection point when it gets easy and works well with everything 

There are massive efforts right now to make OSGI easier, and they do work very well, by themselves.

What is lacking in the above is interoperability at a level that is easy, stable, tutorialized and fully tooled at the Eclipse plugin level. It needs to get there, and then stay out there long enough for everyone else to cross tool to it.

Translation: They don't have mature stable versions that work seamlessly with all other tools I already use everyday.

The best example for this is Maven. I've been using it everyday for 7 years, but only recently has it become pain free. Before it worked flawlessly with my IDE, my continuous integration server, and had it's own repository manager, it was a freaking pain in the butt. To love Maven was to hate Maven, in those early years.

This OSGI getting easy thing - it's going to happen. When it does, all my projects will be OSGI projects. Guesstimate based on current trends - January 2011

What Shape Will It Take?

My best guess is that it might be something such as M2Eclipse and/or BundlorEclipse working together within a Tycho platform. But since I haven't really yet figured out which of those does which, and how they overlap, that's just a crazy comment that only serves to demonstrate my ignorance. 

One of the nicest things happening, just as the tools threaten to begin to work together, is that new ones such as Gradle are appearing to upset the whole apple cart. It's having the opposite effect of the consolidation that I'm waiting for, but it's still super appreciated. Great stuff to for the older designs to compete against.