(To my fellow 30-dayers: It has been a while since my last post in the 30-day challenge category – at least if you think of how brief it is. But worse, I am also behind the schedule. My goal was to have the first release candidate on the 15th. It is the 17th and I am not quite there yet. Read on for details)
Every now and then, the Eclipse Project goes through quite significant changes (OSGi and RCP in 3.0, P2 now in 3.4). And when the platform moves this fast, everybody living above feels it. New features are not well documented or are not very stable. Tooling for plug-in developers lags behind. Things that used to work before, are now broken.
That is really hard to avoid, even though backward compatibility with the previous release is a hard requirement for the Eclipse Project. I was part of the Eclipse Platform Core team in 3.0 (shipped in 2004) and even though we were having lots of fun with the move to OSGi and the birth of Equinox, it was a lot of work having to implement the new functionality and at the same time make sure all the existing use cases continued to work. And, as usual, some corner cases we missed were only discovered close to the release date, or even right after, when most people will finally migrate from the previous release. Many of the OSGi-aware features were only exposed by the plug-in development tooling in the subsequent releases. And even though we felt like all that backward compatibility effort was draining a lot of our time and energy, users would still get mad at us for introducing regressions, when they didn’t really give a damn about OSGi or RCP.
In hindsight, it is clear that all that work paid off when you look at the impact that OSGi and RCP had in the growth of Eclipse way beyond the realm of IDE frameworks. People are using Eclipse as a platform for embedded and server-side applications, or rich client applications you could swear were native. OSGi itself had a boom in adoption (and features) since when it was adopted in Eclipse and moved from niche technology into the mainstream.
I am sure the same is going to happen with P2, probably in smaller proportions (given its scope). We will be taking its features for granted two years from now, and the pain of change will have been long forgotten. And the good people developing P2 know that. But, this time around I am…
…on the other side of the fence
The plan of shipping TextUML Toolkit 1.0 (scheduled for June 30th) on top of Eclipse 3.4 (scheduled for late June – yes, that should have raised a flag) proved to be quite a challenge. I have had minor problems with the latest Eclipse SDK milestones, which I could work around, but more recently I have faced more serious, blocking issues. And even the non-blocking problems and difficulties, which are just time wasters, grow in importance when you are in a tight schedule.
So I stepped back and decided to and develop and ship the TextUML Toolkit 1.0 on Eclipse 3.3, which was last year’s release. It was not an easy decision, as I will be missing many improvements and fixes (some of them to pretty significant issues) made in the UML2 and EMF components, which are the main requirements. But at least I should be able to move forward in a more predictable pace, and be more confident I have a chance of meeting the June 30th deadline, even if quality might suffer. On the bright side, thanks to backward compatibility, the same update site should still work with 3.4, so users using the Update Manager/P2 in Eclipse 3.4 should be able to install the TextUML Toolkit features, and get better performance and stability.
What makes me feel good is that backward compatibility continues to be one of the Eclipse key values (e4 rumors aside), so regressions receive high priority and are fixed as quickly as possible. The least we (end-users and product providers) can do is to diligently report them.
