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.
On the other hand, the changes required to get this working on
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.