OSGi DevCon

Yesterday I and many members of my team took a trip up to Hammersmith to attend OSGi DevCon. Attached to the JAX London conference it is a day of talks and tutorials on the dynamic module system that is OSGi. This was the first time OSGi DevCon had been run in the UK so it was a great opportunity to head down and see what was being said. In addition Ian Robinson was going to spend 30 minutes talking about Apache Aries, an Apache incubator I am a committer on.

Looking back on the agenda I realise I did not actually attend that many of the OSGi talks. I bumped into some people I know from the OSGi UK User Forum and took the time to find out what they are doing.

I missed the keynote, which I hear was very good by Ted Neward. I had aimed to arrive for the first OSGi talk at 10:30 and arrived in time. Shaun Smith from Oracle gave an overview of the soon to be released OSGi JPA2 spec which I had been keeping an eye on, so I didn't learn anything new, but it was well presented with some slick slides.

I then went to Mike Keith's (also of Oracle) talk titled "OSGi and Java EE: Friends or Foes?" which I think was slightly misnamed. It was more of an OSGi for Java EE developers talk. It had a good introduction to OSGi and talked about how the OSGi Enterprise Expert Group are working on bringing Java EE standards to OSGi so they work nicely in an OSGi environment. Despite knowing what he presented it was done with a flare of humour that made it really enjoyable.

After lunch I sat in on a talk about the Eclipse API tooling. These are some extensions for the PDE tooling to detect when an incompatible change to the API are made. It all looks very interesting and I am hoping to take a look at the tools ant integration, but because it was built to support the Eclipse API and as a result is built around the Require-Bundle capability of OSGi, not Import/Export-Package capability. As a result the tooling is of limited (if any) value to an OSGi developer. This is a shame, but I am assured that they are working on the problem. They are also working on bringing this to normal Java projects in eclipse, but in my view they would be better off supporting Import/Export-Package first. Of course I was invited to contribute to the tooling, but that would be problematic.

While I was in a few sessions in the afternoon the subject material wasn't particularly interesting to me. It wasn't until the Tools panel that I got interested again. Improving the tools for OSGi development seems to be one of Peter Kriens pet projects. I happen to use both PDE + ant and maven + bnd in different environments and from my perspective the PDE + ant combination beats the maven + bnd combination hands down, but I appear to be in the minority (I am told that once I have been using maven for eight years I will love it as much as I love ant). I was a bit disappointed by the tooling panel. I was hoping for a little more discussion and idea sharing, but there was not much of that. Perhaps the most interesting part  was when a member of the audience asked for some standard headers to encode information on where the source code repository is located, and where to raise issues when bugs are found. Since I am primarily a closed source developer it is not something I care too much about, although I do understand the problem. Peter Kriens' view is that the source should be in the OSGi bundle and that jar file size is no longer an issue. I disagree with this view very strongly. First off when you consider an application the size of eclipse adding the source into every bundle will increase the download size of eclipse significantly. While for an individual bundle it might not be an issue, for a whole application it gets to be significant. The second problem is one of contamination. Not all Open Source licenses are compatible and some can cause significant contamination issues, viewing or understanding the source could prevent or cause issues if you work on other projects. As a result I think having a URL in the bundle metadata is absolutely the right solution, once it is there any debug tools can use it for debug, but you can have a policy in the tools to prevent it.

The final two sessions were on what is coming in the OSGi Alliances enterprise spec and about Apache Aries and Eclipse Gemini. It is difficult for me to be objective on these talks because I've been so heavily involved in defining the enterprise spec, and am an Apache Aries committer.

In the end I had a very enjoyable day which was only let down by the late finish (I got home after 1am). Not all the talks were interesting, but they never are and being attached to JAX London meant that if a particular session didn't interest you there were others sessions you could attend.