Jul 12th, 2008, 04:11 AM
Tooling: Developer assistance with OSGi Versioning policy
I'm sorry, this post is gonna be a long one (I even need to split it into two comments ;-) ). I hope there's gonna be someone to read it nevertheless - as it includes some fears why I'm still unsure to introduce S2AP or OSGi in general into our development teams. Please tell me your opinions!
One of the bigger problems I see coming with the introduction of OSGi and S2AP in our development process is the required level of discipline of the developer and especially the consequences when the developer once fails having the discipline.
I'm talking about the versioning of modules and the dependencies among modules and their respective versions. This is something completely new to me and all of the developers around me and thus requires quite some change of mindset.
The good news is, that the S2AP Tooling in eclipse very well supports us while doing the change of mindset: It provides a dependency container which is capable of only seeing those Classes in the other project that I am really "exporting" there (great feature!) and will particularly have a look at the version I specified in the various MANIFEST.MF files of the depending projects. While this works well in my eclipse environment, it still does not prevent me from checking in code, which actually would require an increase of the bundle version number - and that's the required discipline I'm talking about. It is the responsibility of every developer to be aware of that fact!
|- MANIFEST.MF: Bundle-Version 1.0.0
|- Exported Interface Foo
|- Private Class FooImpl implements Foo
|- MANIFEST.MF: Import-Bundle: Bundle A;version="[1.0.0,1.1.0)"
|- Class Bar has a reference to Foo
Problematic Use Case
I'm having both bundles checked out in my eclipse workspace. Tooling makes sure, I'm only using Foo from Bundle A in Bundle B, which correctly imports version 1.0.0 of Bundle A.
Imagine now, that I do a change in Interface Foo. Be it a change that "by chance" does not break backwards compatibility (i.e. insert a new method) or a change of a method signature or even worse, the removal of a method from the interface.
In eclipse, I would typically do a refactoring - and thus, the depending bundle B will be updated automatically as well - no problem so far. I could even checkin that code. Continuous integration builds would work, bundles would be created, possibly even automatically deployed to my S2AP platform. As long as those two bundles are the only two depending on each other and as long as both are deployed (e.g. as part of a par package) at the same time, it might even work for a long time (not talking about hot replacement that might one day be of interest as well).