Comments on: Supporting Multiple Versions of Eclipse http://blogs.ilog.com/brms/2008/03/18/supporting-multiple-versions-of-eclipse/ Commentary and news on business rule management systems and rules engines Tue, 07 Oct 2008 15:29:08 +0000 http://wordpress.org/?v=2.3.2 By: ILOG BRMS Blogs » Blog Archive » IDEs and Code Branches: A Cry for Help! http://blogs.ilog.com/brms/2008/03/18/supporting-multiple-versions-of-eclipse/#comment-1171 ILOG BRMS Blogs » Blog Archive » IDEs and Code Branches: A Cry for Help! Fri, 01 Aug 2008 09:27:36 +0000 http://blogs.ilog.com/brms/2008/03/18/supporting-multiple-versions-of-eclipse/#comment-1171 [...] tools or processes to deal with this. Should I be using GIT or IBM Jazz, Mylyn, IntelliJ IDEA or something else entirely? Can it really be the case that developing software 60+ years after Bletchley Park still feels so [...] […] tools or processes to deal with this. Should I be using GIT or IBM Jazz, Mylyn, IntelliJ IDEA or something else entirely? Can it really be the case that developing software 60+ years after Bletchley Park still feels so […]

]]> By: Daniel Selman http://blogs.ilog.com/brms/2008/03/18/supporting-multiple-versions-of-eclipse/#comment-608 Daniel Selman Sat, 22 Mar 2008 02:45:21 +0000 http://blogs.ilog.com/brms/2008/03/18/supporting-multiple-versions-of-eclipse/#comment-608 Eric, thanks for the clarifications. I'm also going to pick up a copy of <a href="http://www.amazon.com/Eclipse-Building-Commercial-Quality-Plug-Ins/dp/0321228472 ">your book</a>. 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... 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…

]]> By: Eric Clayberg - Instantiations http://blogs.ilog.com/brms/2008/03/18/supporting-multiple-versions-of-eclipse/#comment-576 Eric Clayberg - Instantiations Thu, 20 Mar 2008 04:36:52 +0000 http://blogs.ilog.com/brms/2008/03/18/supporting-multiple-versions-of-eclipse/#comment-576 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. 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.

]]>