OSGi: Not Easy to Use. Not as Productive as it Should Be 📎
Rod also clarified this statement:
"I’d like to add some clarification here, and say a little more about our experience with OSGi and my conclusions from it—note the emphasis on my, as my opinions aren’t always those of SpringSource or VMware. "We made a major investment in OSGi in creating our dm Server product. We subsequently took that technology to Eclipse, where it continues to move forward, with our continued input. We have an ongoing revenue stream from our OSGi-related technologies,with customers including some household name companies. We plan to maintain our current level of commitment to OSGi. "The lessons I personally drew from the experience were that: (a) OSGi is a great solution for complex applications with stringent modularity requirements;
(b) typical business applications (from which we make the bulk of our revenue) don’t have such requirements;
(c) our efforts to reduce the complexity of writing server-side OSGi applications were promising, but the road to simplification was longer and less certain than we’d hoped.Thus continuing down that road at the Eclipse Foundation, in partnership with other companies and individuals, was a natural move.
"I don’t think OSGi is a bad technology—merely one that isn’t applicable to every application out there and one which therefore didn't belong at the core of our business. If you don’t have modularity requirements, the simplest thing that can possibly work won't have a module system. I applaud the fact that the Virgo project continues to make progress in simplifying the OSGi experience, and am proud that our engineers play a major role." Rod
[theserverside.com] I agree with (a) particularly with (b) and can imagine (c). I was able in the past to Kill Some OSGi Projects just by asking high level questions. BUT: I'm really looking forward to Jigsaw.