aspose file tools*
The moose likes IDEs, Version Control and other tools and the fly likes OSGI: Dependency Hell Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » IDEs, Version Control and other tools
Bookmark "OSGI: Dependency Hell" Watch "OSGI: Dependency Hell" New topic
Author

OSGI: Dependency Hell

Joshua Smith
Ranch Hand

Joined: Aug 22, 2005
Posts: 193
Jeff, Paul and Simon-

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?

Thank you and welcome to JavaRanch.

Josh


Rational Pi Blog - Java, SCJP, Dev Bits- http://rationalpi.wordpress.com
Paul VanderLei
author
Greenhorn

Joined: Apr 12, 2010
Posts: 17
Josh, first of all, your experiences are actually the norm, in my experience. Moving to SOGi is not easy if the legacy application has not paid proper attention to modularity. I recently read a great blog-rant about this very topic: http://techdistrict.kirkk.com/2010/04/12/osgi-feast-or-famine/

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.


http://equinoxosgi.org
Jeff McAffer
author
Greenhorn

Joined: Apr 13, 2010
Posts: 15
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.

http://equinoxosgi.org
Michael Swierczek
Ranch Hand

Joined: Oct 07, 2005
Posts: 107
    
    1
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.
Jeff McAffer
author
Greenhorn

Joined: Apr 13, 2010
Posts: 15
I don't know of any books that cover that topic in detail.
Joshua Smith
Ranch Hand

Joined: Aug 22, 2005
Posts: 193
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.

Josh
Paul VanderLei
author
Greenhorn

Joined: Apr 12, 2010
Posts: 17
I've been using OSGi in production for over ten years.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: OSGI: Dependency Hell