OSGi Tool Summit Recap

Last Friday, March 27th, Jeff McAffer and I attended the OSGi Tool Summit graciously hosted by LinkedIn:

OSGi Tool Summit

There were many topics discussed, here are the big ones in my opinion:


Now that we have all these bundles everywhere, we have to store them somewhere, right? There is an OSGi RFP 122 out for an OSGi Bundle Repository (OBR) that aims to solve some of this problem. If you’re interested in RFP 122 and OBR, Hal recently blogged about this topic. I expect to see this topic becoming more important in the future as more people adopt OSGi and need a place to store bundles. Also, it’s interesting to note that there are also some commercial offerings that are popping up like Yoxos and some Maven-based solutions.

Application Model

OSGi bundles are great, but sometimes it’s cumbersome working with just bundles. People want to work with a higher level description of bundles. In short, people want a bundle grouping mechanism. I tend to agree that having an ability to group bundles and in Eclipse land we realized this early in the process. At Eclipse, we have developed the concept of features and product definitions to alleviate the pain of managing bundles. In Eclipse 3.5, product definitions were enhanced to support a lot of OSGi use cases like the ability to set start levels and properties. At EclipseSource, we even use product definitions to deploy server-side OSGi applications.


People say pictures are worth a thousand words and the OSGi community wants to visualize their bundles. At the summit, we discussed the topic of visualizing bundles and I demonstrated the visualization tooling in PDE:


The PDE Visualization tools allow you to quickly see why you depend on a certain bundle and some other cool things. These tools are just a start and adding support for packages is the next logical step. People also want it easy to see circular dependencies and dependency extent. If you have any ideas on how to improve the visualization tooling within PDE, please file enhancement requests.

Build Consistency

There are many people out there building large scale OSGi-based applications. The experience reports from people were gripes about the difference in headless and IDE environments. It’s simple, people want a consistent OSGi build story when it comes to the IDE and headless.

Visibility Fidelity

The general goal here is to find a way to eliminate any bundle compile and runtime differences. It doesn’t help when at compile time, you have a linear classpath and with OSGi, you have a directed graph classpath. In Eclipse and PDE, we try to enforce classpath visibility by setting access rules on JDT’s excellent compiler.

Version Policies and Management

I always say that without a good versioning story, modularity is worthless. In my opinion, I find it tragic that in the Java community we tend to treat versions as a marketing tool rather than to signify contractual changes. In essence, most people like to bump versions randomly or to beat the version of a competitor’s product. If you look inside the OSGi specification (section 3.6.2), there is very little said on how we should version our bundles and packages. Actually, this is the only thing said:


This is actually not a bad policy. At Eclipse, we build on this policy and treat version numbers as sacred. I encourage anyone buliding OSGi-based applications to review the Eclipse version numbering guidelines. I also had time to demonstrate PDE API Tools which assists developers in API maintenance issues like binary compatibility problems, version number issues and identifying usage of non-API code between bundles:


I plan on blogging about the topic of OSGi and version numbers in a future post since I’m passionate about this topic, so stay tuned!

Developer Use Cases

One of the most important things we did at the tool summit was to formulate OSGi developer use cases. That is, try to trace the activity of a bundle developer from the start of a new project all the way to deployment. By having a set of solid use cases, it will help us see where the holes are in the current tooling.

I believe this was the first time you had the OSGi tooling teams of Netbeans, Eclipse PDE, Sigil, BND, Felix, Maven, OPS4J/PAX, IntelliJ and SpringSouce Tools in the same room. It was great, we didn’t yell at each other like I thought, we actually discussed and debated things. I was also convinced that I should rename PDE to BDE, never use the word ‘plug-in’ and work on making PDE usable by the traditional OSGi community.

In the end, I think the most important outcome of the summit was to bring the right people to the table and start the OSGi tooling discussion. Now that we have done that, expect to see more OSGi tooling collaboration. What do you think is missing from the current tooling story around OSGi?

  • Posted at 19:49, 2009-03-31

    For me, PDE’s most significant restriction is the assumption that the project’s contents are laid out in ‘expanded bundle’ format. This leads to hacks like build.properties having an ‘include’ to avoid bundling source etc or project metadata. Almost every other Java project has a set of ‘src’ and ‘resource’ folders which together are copied to the build or bin dir, which is then used as the contents of the runtime classpath.

    PDE doesn’t have the concept of resources (automatically generated or otherwise) other than the top level of the project. If it were amended to allow the contents of the bundle to be the contents of the ‘bin’ or ‘build’ dir (or whatever it is defined in the .classpath) then they could be arranged as the project wanted, not as the tool wanted.

    The manifest.mf is a special case of this same problem. Ideally this too should allow it to be built (eg from bnd) at rubtine but allow editing in a src folder (e.g. src/resources/META-INF/MANIFEST.MF).

    Many people I know have given up on PDE (and PDE build in particular) because of these pointless restrictions. To make a general bundle environment that people will want to us, this needs to be addressed.

  • Posted at 20:10, 2009-03-31

    Great summary of the meeting.

    To be clear, OSGi does not provide a hierarchical class path. OSGi provides a directed graph class loader structure with the graph edges representing Java packages.

    Don’t forget to include Maven and BND in the list of tools represented at the meeting!

  • Lars
    Posted at 22:12, 2009-03-31

    I downloaded org.eclipse.pde.visualization.dependency out of cvs into a 3.5M6 and started it. The dependency graph view shows but stays empty. What do I need to select to see same data?

  • Lars
    Posted at 22:20, 2009-03-31

    Chris, thank you, works perfectly. Very nice tool (and a good code example for Zest).

  • Simon Chemouil
    Posted at 11:20, 2009-04-01

    Excellent post and summary of the situation! I look forward to PDE becoming a more general OSGi bundle development environment; that would be great not only for developing non-Eclipse OSGi applications, but also for making Eclipse plugins less tied to Eclipse specifics by giving more tooling to Eclipse developers.

  • Matthias Kuespert
    Posted at 22:38, 2009-04-24

    Great post! Especially the “… convinced that I should rename PDE to BDE …” caught my attention: I always believed the name would make it 🙂

    Mid 2007 I started a Eclipse-plugin to turn JDE into a BDE using BND – sadly it always remained a low-priority toy project. The remains are available here: https://code.google.com/p/bde/ – at least they may serve for inspiration.

    Main intentions were to provide:
    – a BND configuration editor
    – a bundle-builder that assembles a bundle jar using BND on each source-code change
    – a straightforward way to configure OSGi run/debug-configurations: one page for framework config, one for startlevel-based bundle config.
    – generation of a Maven pom … but that’s obsolete now that we have m2eclipse

    Unfortunately I never got to integrating the Pax toolchain – especially Runner and Exam- that sure would add more flavour …

    But why ‘rename’ PDE? PDE is perfectly ok for Eclipse-plugin development – should not BDE be a layer between JDE and PDE since Eclipse is based on OSGi?

  • Frederic
    Posted at 02:41, 2009-05-27

    >To address your layout issues, the PDE team is committed to fixing the issue in the 3.6 and 4.0 timeframe.
    >We’ve been tooling bundles (plug-ins) for a long time so there’s some legacy we need to shed.
    >When we receive constructive feedback from the community in terms of bugs and enhancement requests, we’re able to make progress.

    That’s great news Chris! I really think there should be more collaboration between OSGi technologies in order to come up with more productivity for developers, and this Tools Summit was an excellent step.

    In the mean time, for Maven users (and Spring DM users as well) you’ll find some integration tips over here: