This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I took 2 or 3 serious weeks making an effort to componentize (OSGI style) an existing application and found that every dependency that I ran into was a nightmare. Libraries from the Apache Software Foundation were already OSGI enabled. Almost nothing else was. This meant that I had to create OSGI-enabled versions of every dependent library that the application used and one depended on another, and that depended on another etc. In the end I gave up and decided that an application needs to be designed with OSGI from the beginning and some standard mechanism for OSGI-ifying non-OSCGified libraries needs to be established before I'm interested in writing OSGI applications.
I hope this doesn't sound negative, because I really did see a lot of advantages to OSGI and felt that it was one of few ways available for solving the problem of application plug-ins, but it was painful to saw the least.
So my questions to you...
What are the options for handling non-OSGI-ified dependencies when creating OSGI-enabled applications?
What are the ways for handling non-OSGI-fied dependencies in the context of Maven (which is how we are handling all of our dependencies)?
How is Project Jigsaw going to play into all of this?
Your specific question about how to deal with non-OSGi code is addressed at length in our book. Chapter 22 presents 4 different approaches to bundling a JAR: Bundling by Injection, Bundling by Wrapping, Bundling by Reference, and Bundling using bnd.
The bottom line is that it's never simple. BUt if code is modularized ahead of time, it's much easier to move to OSGi.
As Paul says, making non-modular systems modular can be challenging. Most of the time it is not "OSGi" that is the problem but rather modularity itself. Being modular forces you to think about the boundaries between modules. For the most part OSGi is the messenger/enforcer, not the root cause.
Note also that Eclipse hosts a project called Orbit (http://eclipse.org/orbit) that has many third party libs "bundlized" and ready for use in OSGi-based systems. The Spring guys have something similar in their enterprise bundle repository.
Joshua Smith asked my question for me. I work at a tiny company with one monolithic Java web app.
It would be wonderful if the app was modularized and split into OSGI bundles that we could transparently update on-the-fly. But the first step is making the partitions between the different modules in the application very strong - and that's no mean feat with an antique Struts 1.x app with a few hundred thousand lines of code.
So, I am asking the next question to the authors or to anyone else: what book or books would you recommend with good practical advice for refactoring applications to be more modular? Thanks.
Joined: Apr 13, 2010
I don't know of any books that cover that topic in detail.
Joined: Aug 22, 2005
Thanks guys. Those look like some great resources and I'll check into that section of your book.
In my mind, these problems are the most important ones to solve for the sake of OSGI adoption. I was at a Java User Group meeting last month and a very bright speaker was chatting with people afterward. Someone brought up OSGI and he asked, "But does anyone use that? I mean, for Eclipse plug-ins sure? But does anyone in this room know anyone that has used this in production??" The room was silent. I spoke up, mentioned Glassfish and also described my experience. One other person said he had heard of similar experiences and it scared him away.
Still, the problem of modularity is still out there. It's not like there are many other options available for solving it. Maybe the NetBeans platform since it does a plug-in sort of infrastructure, but that's pretty desktop specific.
Thanks again for the information guys.
Joined: Apr 12, 2010
I've been using OSGi in production for over ten years.