Supporting Multiple Versions of Eclipse
The tutorial from Instantiations by Daniel and Eric on building commercial quality Eclipse plug-ins was a nice review of the core capabilities of the Eclipse platform, annotated with some best practices. They also spent quite a bit of time on the requirements of the Ready for Rational certification from IBM.
They included a couple of slides at the very end of their talk that were very relevant to Rule Studio — how Instantiations supports multiple version of Eclipse (in their case 3.0, 3.2 and 3.3). They have experimented with various techniques (including using different code branches, which is what ILOG does) but have now settled on a single code-base (single branch) that they translate using a custom tool to source code specific to each version of Eclipse. Code comments parameterize and drive the source translation approach. It sounds very challenging but the logic is that 95% of their code is independent of Eclipse version and this approach allows them to fix a bug in a single branch without having to deal with merges into different code branches. Unfortunately it also means that they are locked into JDK 1.3 language level for WSAD 5.1 support! They even had to backport some new Eclipse features to older Eclipse version, such as the Jobs API!
I’m skeptical that this approach could work for Rule Studio but it is true that merging bug fixes into all the branches we support (JRules 6.1, 6.5, 6.7 and trunk are the most active branches) is a drag on productivity.
I’d be interested in hearing how you and your company deals with supporting multiple versions of Eclipse.
March 20th, 2008 at 4:36 am
Our technique works very well and is easy to use. We only really need it for about 2% (or less) of our product code. Each code variations is simply seprated by special comments and the proprocesor tool takes care of exposing one variation or another depending on the Eclipse version target. It makes it very easy to keep all of the logic for a speciifc class or method in one place. Often the Eclipse version differences effect only one line of code, and we generally only need two variations (e.g., Eclipse 3.2 and above vs. 3.1 and below). It also means that you can make logic changes to both variations at the same time in the same context.
As to JDK 1.3, that depends on the product and the customer base and has nothing to do with the technique we use to support multiple Eclipse versions. For products where we still have significant WSAD 5.1 users, we stay with JDK 1.3 source compatibility (once we drop support for WSAD 5.1, we will switch those products to JDK 1.4). For most of our products, we stay with JDK 1.4 source compatibility, and we have a couple of products under development that will target only Eclipse 3.2 and above and are using JDK 1.5. Backporting some features is also a result of supporting older Eclipse versions while wanting to use newer Eclipse APIs. We have only done that in a couple of cases where the Eclipse API was reasonably self-contained and compatible with the older Eclipse version.
March 22nd, 2008 at 2:45 am
Eric, thanks for the clarifications. I’m also going to pick up a copy of your book. I leafed through it at EclipseCon and was impressed, but it was too weighty to carry back to Europe!
Any chance of publishing your preprocessor? I’d love to give it a spin…