• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

OSGI: Dependency Hell

 
Ranch Hand
Posts: 193
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 125
1
Clojure Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't know of any books that cover that topic in detail.
 
Joshua Smith
Ranch Hand
Posts: 193
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've been using OSGi in production for over ten years.
 
I have gone to look for myself. If I should return before I get back, keep me here with this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic