[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