OSGi Tool Summit Recap

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

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

Repositories

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.

Visualization

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?