Thursday, August 23, 2007

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

7 comments:

  1. Peter, PDE supports pluggable OSGi frameworks via an extension point (http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.pde.ui/schema/osgiFrameworks.exsd). This makes it very easy to use different OSGi frameworks. However, there hasn't been much activity outside of the Knoplerfish folks (http://dev.eclipse.org/mhonarc/lists/pde-ui-dev/msg00260.html) on adding clients to this extension point.

    I would love to see the OSGi community rally behind this support so it would be easier to launch amongst various frameworks. From a user standpoint, you simply select the framework you want to launch against in the OSGi Framework launch configuration.

    Were you aware of this functionality Peter?

    ReplyDelete
  2. I was aware of the possibility to add more framework launchers but I have not tried it so far, PDE and me decided to live apart for some time and I went back to my old love JDT :-)

    However more important is not to become overly dependent on Eclipse, that is why I also added the shell scripts in addition to the launch files. If I have time, I'll check if Netbeans has a launch facility as well, or hope that others will add this to this project.

    We are working inside the OSGi on a proposal to standardize the launching of frameworks, that will make all this easier.

    Anyway, I do hope the framework vendors do support this feature, it seems quite simple and non-intrusive to add such a plugin.xml to a framework JAR file.

    Kind regards,

    Peter Kriens

    ReplyDelete
  3. To further the diversity, there's also the Pax-Runner project at OPS4J which lets you quickly deploy to all three frameworks from Maven:

    http://wiki.ops4j.org/confluence/display/ops4j/Pax+Runner

    Alin Dreghiciu is working on the next generation of Pax-Runner, which involves some really cool ideas:

    http://wiki.ops4j.org/confluence/display/~adreghiciu@gmail.com/Pax+Runner+NG

    ReplyDelete
  4. Peter, PDE loves you still and wishes for you to come back some day ;)

    ReplyDelete
  5. Hello all,

    In the beginning, when I read the blog post, I thought in a naive way: Xmmm, what a coincidence, some weeks ago, I had to migrate at another implementation too, which I found a rather annoying procedure. I checked out the multi-osgi project, wandered around the trunk and tonight as I re-read your post, I realized that the conversation there, triggered this (correct me if I am wrong). The conversation in OSGi list was about my initial belief of SAT's erroneous behavior, when later, was proved that the problem was at KF. To let others know my situation, I used KF alongside with SAT for my project and after realizing that something wrong was going on, I had to switch on Equinox. The procedure was rather painful, by transforming bundle-start scripts and other annoying details. Well, I would like to participate on this (already registered at multi-osgi). I think that an independent entity for this matter would be great in terms of portability, flexibility and testing across different platforms. I have only Equinox and KF experience but I think I will manage if anything comes up.

    Best Regards,
    Aggelos

    ps: If someone would like to see the aforementioned conversation I would be glad to give him the link by email.

    ReplyDelete
  6. Hi Peter,

    Here is a new tool (eclipse plugin) that is based on Pax Runner and uses the extension points provided by Eclipse >= 3.3.0 that Chris was talking about.

    http://wiki.ops4j.org/confluence/x/0QBN

    ReplyDelete
  7. Alex, I give in :-) I just killed the Google project because I think Pax Cursor is a much better solution and you really take time to improve it. nice work!

    Peter Kriens

    ReplyDelete