One issue we have is that Drools cannot support more than one Eclipse version using the same code base. We are dependent on some internal eclipse java classes to get the rule debugging working (the Java debugging was not really written to be extended / reused, at least not when we implemented debugging and I guess the situation is still the same), and those internal apis tend to change a little every release. I just checked and a few methods were added again. This means we would have to maintain two parallel branches, one for Eclipse 3.4 and one for 3.5.

Based on the impression that they are targeting Eclipse 3.5 GA end of June, I guess the following options are possible: 1. after Drools 5.0 GA (supporting Eclipse 3.4.x) this weekend we move to Eclipse 3.5.x, all new features implemented for Drools 5.1+ Eclipse IDE will be for Eclipse 3.5 only 2. after Drools 5.0 GA we keep working on this code base (supporting Eclipse 3.4.x) and we branch the last week before Drools 5.1, so at that point both Eclipse 3.4 and 3.5 are supported for Drools 5.1, after that all new changes are for Eclipse 3.5 only 3. after Drools 5.0.GA create a new Eclipse 3.5 code base immediately, next to the Eclipse 3.4 code base, and commit all changes to both, until we decide the 3.4 branch no longer needs to be kept up-to-date with the latest features Obviously, option 3 requires a lot more work. I'd go for option 2 as it has the advantage of being able to support both 3.4 and 3.5 for 5.1, but that means we won't be able to migrate to Eclipse 3.5 soon.

On the other hand, the changes required to get this working on Eclipse 3.5 are probably pretty minimal, maybe we can write some automatic patch script that could automatically patch our Eclipse 3.4 code so it supports 3.5, thus removing the need to maintain two separate branches? And JBoss Tools trunk could use the patch script and include the Eclipse 3.5 version, would that be possible?