How To Kill An OSGi Project - With 10 Questions

OSGi focusses on modularity and it is right now (future may change it) the only viable way to split your application into modules with well-defined dependencies. It solves, however, "only" the technical problem - which is actually relatively easy. Before you going to introduce OSGi into your project, answer the following questions:

  1. What is your versioning scheme for modules(bundles)? Do you care about minor versions, major versions etc?
  2. Whats your scm strategy - do you plan to open and maintain a branch for every version of a module? How many branches do you plan to maintain? (with svn? :-))
  3. How many versioned modules will be active at the same time in production?
  4. How the system is going to be tested? Each module and all the combination of modules. Every version will increase the complexity significantly.
  5. What is your release-management strategy? Do you really plan to provide customer-specific module combinations? What is your bug-fixing / patch strategy (trunk, branch)?
  6. Do you really want to replace modules in running system? If it is a serverside system - what happens with in-flight transactions?
  7. If it is an Eclipse-RCP application - are you even allowed to expose the plugins to the end-user? (in the majority of my projects, we had to disable the update manager in production :-))
  8. What is your software distribution system - many companies have already a software-distribution system in place. Often not only the application, but also the JVM are packaged into one binary file and entirely installed. Incremental updates are often impossible.
  9. What is exactly the contract between the modules? Only a Java-Interface? If so - what to do with direct relations between JPA-entities. If you disallow direct JPA-relations - you will probably see a huge "domain" package with all domain objects inside it. You will need to provide "friend" relations between modules as well.
  10. Is maven the canonical representation of modules, OSGi, or both? A single representation would be the best. Will maven module versions be reflected in the OSGi bundle versions?
The major OSGi-challenge is not the technology, rather than the governance of your modules and bundles. The problem is very similar to SOA.

For most enterprise applications you will get only one variant of your business logic, or even UI - so you will end up with modules, which will probably never be replaced. Because of additional complexity - you will probably test and deliver the whole system at once.

If you are building an IDE, platform or a server - governance, modularization and versioning are a major part of your problem domain / functional requirements. You will have to solve that anyway. It is far more likely, that someone will have to install a new driver to an application server, or even maintain different versions of the driver at the same time. IDEs without plugins are also extremely rare.

Replacing an algorithm in a business application is far more uncommon - often even not allowed. Its just crazy to introduce a modularization solution and then not use it.

[See also "Real World Java EE Patterns, Rethinking Best Practices" book, Page 253, (Premature Encapsulation Is the Root of All Evil) for more in-depth discussion]


"it is right now (future may change it) the only viable way to split your application into modules with well-defined dependencies"

I disagree. Another approach is using IOC and enforce IOC in your build process.

Posted by phil swenson on March 08, 2010 at 05:19 PM CET #

Hi Phil,

I'm glad, that you only disagree with the introduction to this post :-)

Enforcing IoC during the build process may be tricky. In case modularization is really needed, I would rather try to combine OSGi with maven right now.

Funny: although modularization is beneficial for decoupling of source artifacts, we sometimes deployed a modular project with: "jar-with-dependencies" maven assembly configuration. We even delivered JVM with the deployment - just to minimize possible side-effects in critical projects.

Thanks for your comment!,


Posted by Adam Bien on March 08, 2010 at 08:10 PM CET #

Hi Adam,

it is funny to read that even Java savvy people have problems wrapping their head around the concepts of OSGi. It is true that it doesn't solve all your problems, but it makes the management and the focus on the real ones easier. I also believe that OSGi is promoted for the wrong reasons. Hot plugability for one is really hard to achieve and not always desired, especially with respect to testing, no doubt about it. What I think is most valuable is the enforcement of modularity. Now you can't cheat and violate the rules of module contracts (well, you can, but it gets really hard compared to plain Java). Except for points not relevant in my opinion like hot replacement f.i., we found a way to either adapt our workflow or use tools on top of OSGi to deliver high quality products or even just modules that can easily be used or integrated. This works for us in embedded, as well as enterprise scenarios. So, I guess at least for us the reality proves that it does in fact work. ;-) I admit, it is not easy to get started, but it certainly is worth the effort. Of course, nothing is perfect and I see a lot of potential for improvement. Anyway, thanks for sharing your impression. It's always interesting to see what people struggle with when being faced with new paradigms.


Posted by Mirko Jahn on March 09, 2010 at 03:18 AM CET #

Frankly, we've just included OSGi for two very simple reasons:
1) It's actually pretty easy and integrates well with the Maven build process
2) It means that the plugins (yes we have to support plugins from other parties) don't have to track the versions of all the libraries that we use but don't expose.

Sure, we could roll our own simpler solution, but "rolling our own" would be a heck of a lot harder than just putting in an incantation to the OSGi fairies to do it all for us. (And it gives us better documentation, IDE integration, fabulous tools, and a big community to support people having difficulties.)

Posted by William Billingsley on March 09, 2010 at 08:32 AM CET #

(I realise in the previous comment, the phrase "incantation to the OSGi fairies" sounds rather cavalier. The point is that to our plug-in writers it really is that simple. We happen to know what goes on inside OSGi pretty well, but we don't expect everyone we work with to have to.)

Posted by William Billingsley on March 09, 2010 at 08:37 AM CET #

The question behind OSGi and modularity in general is not about technical issues, It's all about the famous "Time to market".

You cannot be fast If you work on you entire system all the time (unless you have a very small Information System).

Now here is my answers on different points : For points 1, 2, 3, 4, 5 the answer is clear : You have to handle backward compatibility as any integrated system does.
Please read this excellent article talking about Backward compatibilty and versionning policy :

For point 7 and 8, my company found p2 better than their distribution system and took It for RCP deployments : It just works fine.

For point 10. I highly recommend the use of maven Tycho which takes the best of both (dependencies relies on manifest files).


Posted by pascal leclercq on March 09, 2010 at 01:15 PM CET #

Hi Adam,

I am interested in point 9 JPA.

If I have a module with JPA entities, how can I deploy this module in different versions if the data base schema must be updated. E.g. the new version gets additional properties.
I see only two solutions, using different schemas, which means different data for both versions or you must limit your change to optional additional properties.

Any other suggestions?

Thanks for your blog

Posted by Kai Prünte on March 09, 2010 at 02:05 PM CET #

Some of the questions listed above may actually kill an OSGi-based project when the business case for using OSGi is not well-grounded. However, some other questions could be really valuable for OSGi-based and even non-OSGi-based projects. For instance, I don't think that most projects have really thought about a stable technical versioning scheme. OSGi forces us to consider backward- and forward-compatibility and how we support such compability in the future by using well-defined versions and version ranges in intermodular relationships (involving dependencies to the base products).

If a software-architect is about to design an OSGi-based application, the architect has to ask how the degrees of freedom provided by OSGi must be restricted, depending on the project's context.
The architect may ask questions such as:
-How does the component model of OSGi and Eclipse (involving Features) map to our current component model?
-How does the versioning scheme of OSGi match our current versioning scheme? Are they compatible or do we need another versioning scheme with major, minor and service version?
-What is our strategy for initial deployments, updates and patches? Depending on that, we have to set rules for upper and lower bounds of version ranges. Otherwise, it may be impossible to roll out a simple patch.

OSGi because it forces us to consider design-aspects such as modularity, life-cycle management and versioning (which is not a bad thing ;-). On the other hand, I don't think that dynamicity is really a major driver for OSGi. Quite the contrary, enterprise environments have to be stable and deterministic.

Posted by Stefan Bohm on March 09, 2010 at 02:52 PM CET #


"it is funny to read that even Java savvy people have problems wrapping their head around the concepts of OSGi"

Yes - I really question everything, before I introduce it to my project.
Also OSGi,



Posted by Adam Bien on March 09, 2010 at 04:30 PM CET #

I prefer the NetBeans module system to OSGi. OSGi is not the only viable modular system for Java!

Posted by Antonio on March 09, 2010 at 05:49 PM CET #

Perhaps JEE packaging strategy with ears is a better solution :-D ?! I don't think so. I feel very well with the OSGi style, however it is not so handy for a rookie

Posted by openwms on March 11, 2010 at 04:54 AM CET #


For the old style JavaEE packaging the same questions have to be asked. Sometimes I see tons of ejb-jars - without any explicit requirement. It caused just bloat and increased management efforts without any benefit.
But: the WAR-deployment is also sufficient for 80% of all cases. Your ejb-jars are included within the WAR and loaded with a single classloader - and most of the problems are gone.

Just YAGNI, DRY and KISS for everything.

thanks for your comment!,


Posted by Adam Bien on March 11, 2010 at 11:30 AM CET #

Have you considered getting a job at Apple? I hear they hire anyone who is willing to completely slam any other technology that isn't the one they sell by spouting drivel.

Posted by Mada on June 09, 2011 at 02:27 AM CEST #

I started some weeks ago in a big project where we build rich clients with Eclipse RCP using OSGi on the server side.

We build the system with maven tycho and deploy on a WebSphere environment.

Althought the project is far away to be done, we already spent the whole budget and there is a high risk that the management will stop the project!



Posted by Mark on September 25, 2014 at 09:35 PM CEST #

The eclipse way of doing osgi is a night mare. And tycho fits in this.

But if you go with apache karaf and maven it is a clean and lean "no magic" solution to get you out of the dependency hell.

I agree with Adam that gouvernace of modules and dependencies is the main point.

If your domain requires hot deply - it is a problem, no matter what technical solution you choose. That is not an osgi fault.

Everyone is talking about microservices these days - with apache karaf you have an all java microservice operating system right at your fingertipps.

Posted by Guido on September 26, 2014 at 09:12 AM CEST #

I can confirm that Tycho is hell. Stay away from tycho and eclipse/equinox. If you are not sure just check the speed of eclipse. Rather check bnd tools. My happiest moment in life will be when I can run our stuff in karaf built by ordinary Maven.

Also having problems with 9 - most of the modules will have some kind of dependency to a bunch of core things. Guess we will have to just handle that manually via numbers. So '89.

Posted by Anonymous on March 18, 2015 at 12:34 AM CET #

I love OSGi. It is wonderful to work with. When I say that I'm actually talking about the basic OSGi, not blueprint, etc. It feels like that when JEE people started looking at OSGi they screamed: "Oh my god!, there is no XML, we have to fix this!" :-).

I would also say that OSGi is *not* about being able to do runtime updates of bundles. This is something that is nice for development testing, but I would never rely on it in production installations. After X number of bundle updates you always run into a perm gen space exception. Apparently java 8 will not really solve that either.

What I like about OSGi is that you are forced to a good architecture, and it is really simple to work with. I did write my own ServiceTracker since I did not enjoy the provided one, but that is the only complaint I have on basic OSGi.

In basic OSGi there are only 4 interfaces at the core that are important for running bundles. I made an implementation of the runtime parts of those 4 for testing, added a way to fake bundle content. That required relatively little code. With this I'm now running my bundles in JUnit tests and use them as they would be used from any other bundle in my tests. This makes testing truly easy and I don't need to use any mock libs. This is possible because OSGi at the core is very simple! And I love simplicity.

That you can hide the internals and only expose the public API is also a very important and useful feature that promotes API stability. I worked at a customer that were very decentralized and components for their web were being developed a little bit here and there, and they didn't even use interfaces to declare a public API. This resulted in that people called any code they found useful in each others components, and after a while almost nothing could be changed in the code since it would break something and nobody knew what other modules were using in their code. OSGi really solves that kind of problem.

Posted by Tommy Svensson on May 31, 2015 at 07:45 PM CEST #

@Tommy Svensson Looks like you could achieve the same functionality adding a regexp error '^import.*internal.*;$' to your checkstyle rules while enforcing some conventions...

If you decide to implement an OSGi bundle your artifact has to be a "good citizen". Especially it should adhere to the lifecycle rules. Comparatively easy to do if you write a few small bundles for an embedded device. Not so easy if you are developing a large enterprise application...

If you don't address the questions Adam asked you've just found a more expensive way to write monolithic code... :) (Really expensive if you're stuck with the buggy Eclipse PDE.)

Oh, and you really have to think about classloading if you're going to do something like database access or serialization across bundle boundaries...

Posted by Thomas on October 30, 2015 at 11:35 AM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments