Diversity is Good

A couple of weeks ago there was a discussion on the OSGi developer list about a support library for OSGi programmers that is intended to make the life of an OSGi programmer easier. This library was developed on, well lets say, framework E. A developer in Asia tried this library on framework K and found out that the library did not work on this framework. After a couple of messages back and forth the library developer basically said that it was probably a bug in framework K and that the best solution was to let the framework K developers figure out where the bug was.

I made a lot of noise on the list because I think we should develop against the OSGi specifications, not against a particular framework implementation. The fact that it runs on framework E does not mean by definition that it is good, even though I know that the developers of framework E are really good.

Now I have been in this industry for 30 years and I still have not learned to sit still and wait until everybody has forgotten the issue. This stupidity obviously resulted the problem ending up in my lap. Today I decided to run the faulty code on frameworks K, E, and F. This is a lot easier to write down than to do it, actually. Each framework has its own peculiar way of starting and it took me quite some time to get the whole setup running. To be able to switch quickly, I used the aQute File Install bundle. This is a simple bundle that watches a directory and installs/uninstall bundles depending on their presence in this folder. As a bonus, it can also manage configuration data in a similar vein. I then created Eclipse launchers for each of the frameworks.

After this hard labor, finding the bug was not too hard. It turned out there was a misinterpretation of the spec that should be easy to fix. However, it was almost a shame to see how much preparation I had to do to be able to run bundles on multiple frameworks. The setup I had created I thought was quite fancy, it was easy to test all kinds of bundles this way.

I therefore decided to use the altruism of Google and use some of their abundant disk space as a Google project. Wonder if all those Google investors know how their money is spent to support open source? Anyway, I created the multi-osgi project. Within Eclipse you can check this out with SVN (you need Subclipse, Subversive, or some other SVN plugin. The URL to the project is http://code.google.com/p/multi-osgi/source.

The project works quite simple. In Eclipse, you can just find an Equinox, Knopflerfish, and Felix launch in the Run/Debug Dialog. From a shell, you can just switch to the Felix, Knopflerfish, or Eclipse directory and do run (in DOS) or ./run.sh in Unix.

Once you got one or more frameworks running, you can easily install the bundles by just dropping them in the load directory. A good way to find bundles is to go to the OBR site. The input box allows you to type search criteria. For example, you want to install a shell. Just look for "Shell". This gives two bundles from the Apache Felix project. Just click on the download icon and save the file in the multi-osgi/load directory. You should be able to use this shell from the console. Equinox already starts up with a console, so you will get some interaction. Try it!

I will keep maintaining this project for the foreseeable future. However, I would welcome anybody that is willing to add other frameworks into the mix, or write scripts for special environments. Obviously, the committers of the different frameworks or commercial vendors are more then welcome.

Peter Kriens

Help Wanted

Last week I was in Boston at IONA's Waltham offices for an OSGi Enterprise Expert Group meeting. This was a very interesting meeting and well attended by OSGi members. It was pretty intensive because we had so many different subjects to cover. SCA, how to handle WARs and EARs, distribution, database access, making security usable, a new OSGi Component model, hyper-packages (super packages that cross bundles), JNDI, and much more. Looking at the actors around the table and the technical progress it seems clear that this work will have major impact on the enterprise software industry. All the key players were there: Oracle, BEA, IBM, IONA, Siemens, RedHat, and others.

During this meeting it suddenly hit me that we only had vendors around the table. I understand that vendors often take the lead in these efforts because it will enable them to see different products. However, lesson one in software development is that you'd like to have the customers included so that you can focus on the real needs and not the perceived needs. Fortune 500 corporations spend hundreds of millions each year on software development, where are they in standardization efforts? In the end, these are the actors that benefit most when the standards are solid. Look at how easy J2EE turns into a vendor lock-in model because the standard leaves crucial aspects undefined or fuzzy. Good solid specifications make the vendor switching cost low, forcing vendors to compete on quality and performance instead of maximum lock-in.

So how do we get more people from the trenches involved?

Peter Kriens