Supporting multiple versions of Eclipse

Question

I have an Eclipse plugin and I am aiming for 3.1 or 3.2 as a minimum version to support. The problem is that some of my code only works in version 3.5 and above (see my other question: Is there an alternative to CaretListener in Eclipse?).

Now that I have code that works in the older versions and different code that works in the newer versions, is there a way that I can call the newer code only if my plugin is running in version 3.5 or above and then revert to the old code if running anything older?

As a test, I've created two plugins that have the same class within it (just doing slightly different things). I have marked the org.eclipse.ui dependency as a minimum of 3.5 in one plugin and 3.1 as a minimum in the other but I can't get the one that relies on 3.5 to be ignored in older versions...

Can anyone help?

Thanks, Alan

Eclipse 3.1/3.2? I think you should first ask yourself if you really need to support that old Eclipse versions. 3.1 came out in 2005. If some customer/client is using an Eclipse version that old, I'd say you should first focus on encouraging them to upgrade. — Fredrik, Oct 18 '11 at 11:53
Thanks Fredrik, I take your point but version 3.4 only came out in 2008 - it would be nice to at least support that. So, I would still be interested to find out if it is possible, since it is only one dependency that is an issue. — Alan Spark, Oct 18 '11 at 12:05

Paul Webster · Answer 1 · 2011-10-28T12:43:34.897

You could use org.eclipse.core.runtime.Platform to get the org.eclipse.ui Bundle and check the version.

Version ui = Platform.getBundle("org.eclipse.ui").getVersion();
// then do something with that

Register MyListener if >=3.5, and OldMyListener otherwise.

EDIT:

Right, the above is only good for capturing differences in runtime behaviour.

Eclipse supports a couple of tricks for only loading some classes.

The easiest from a development point of view is the trick that @ShiDoiSi mentioned.

Bundle myBundle = org.osgi.framework.FrameworkUtil.getBundle(this.class);
Version ui = Platform.getBundle("org.eclipse.ui").getVersion();
Version cutOff = new Version(3,5,0);
final Executable processListener;
if (ui.compareTo(cutOff)<0) {
    Class pc = myBundle.loadClass("my.pkg.OldListenerProcess");
    processListener = (Executable) pc.newInstance();
} else {
    Class pc = myBundle.loadClass("my.pkg.ListenerProcess");
    processListener = (Executable) pc.newInstance();
}
processListener.execute(targetObject);

Another option that uses more of the eclipse framework would be defining your own extension point so that contributions from other bundles can decide which version to use. Basically it's the same pattern as above, except the version checking is done by the dependency ranges on the plugin the contributes the Executable to run. Depend on org.eclipse.ui [0.0.0,3.5.0) for the old way, and simply specifying org.eclipse.ui 3.5.0 (that's an open ended range on 3.5.0) for the current way. Then you can read your extension and instantiate the class provided.

If you were creating extra plugins for this (a little heavy weight for the 2 differences) you could define a command in your main plugin, and have the extra plugins provide the equivalent handler. The plugins would still have to have dependency ranges so that only one would load for the <3.5 or >=3.5 case. Then using the command API you could execute the command (and the correct handler would run).

ICommandService cmdS 
  = (ICommandService) workbenchWindow.getService(ICommandService.class);
Command process = cmdS.getCommand("my.pkg.ListenerProcess");
ParameterizedCommand cmd = new ParameterizedCommand(process, null);
IHandlerService handlerS 
  = (IHandlerService) workbenchWindow.getService(IHandlerService.class);
IEvaluationContext ctx = handlerS.createContextSnapshot(false);
ctx.addVariable("toAddListener", targetObject);
handlerS.executeCommandInContext(cmd, null, ctx);

Then your implementation of handler would use HandlerUtil.getVariable(event, "toAddListener") to extract the object you need from the ExecutionEvent.

If I understood the poster correctly, he was talking about an API difference, so he would need to compile against two (mutually exclusive) interfaces. — Volker Stolz, Oct 27 '11 at 14:07
Yes, I was talking about an API difference and checking the version at runtime isn't an option. At the moment, I'm resigned to supporting 3.5 as a minimum but would still appreciate any other suggestions. — Alan Spark, Oct 28 '11 at 07:32

score 0 · Answer 2 · answered Oct 28 '11 at 11:57

It sounds to me that you should be supplying two plugins, one supporting version 3.1 to "just below" 3.5, and the other one from 3.5 upwards. So you don't really get to choose, it's basically the Eclipse plugin layer choosing the right one based on your version ranges.

Or if you provide just the compiled class files, then of course you could load the required class dynamically based on testing the version of the running Eclipse.

Supporting multiple versions of Eclipse

2 Answers2