[jbosstools-dev] Moving to Eclipse 3.5 drivers

Max Rydahl Andersen max.andersen at redhat.com
Sat Apr 4 04:27:20 EDT 2009


> 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.
That was what I feared would be the case for Drools. Any chance you 
could identify these so we could do a push for getting the API you 
depend on public instead of internal so
we can reduce this going forward ?
> 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.
Understood.
> 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?
hmm - wouldn't it actually be easier to maintain two separate branches 
than a patch file ? Or at least have the patch file be to "downgrade" 
3.5 code to 3.4  so the codebase "just works" on 3.5 ? Reason: I assume 
there we will be far more dev's having the drools codebase checked out 
using Eclipse 3.5 than 3.4.

/max



More information about the jbosstools-dev mailing list