Eclipse 3.3 and WTP 2.0 is planned to be released soon and I’m considering if we should move now or later.
Previous major Eclipse upgrades have been smooth for me as an user, but a *pain* as a plugin developer since many of the API’s I’ve needed to integrate with WTP DOM and JDT changed. Of course that was all my own fault since I am and were using internal API, but hey what can I do when there is no public DOM editor API and previously there where no public java code completion API ?
Luckily, Hibernate Tools seem to be running just fine under Eclipse 3.3/WTP 2.0, but as you all know we got the rest of JBoss IDE and the plugins from Exadel which is now JBoss Tools to also migrate.
From the first look of things it seems like we can migrate 98% of our code base in JBoss Tools without any compilation issues at least, but what is obvious is that when we first do the move we can’t be compatible with Eclipse 3.2 hence we will be Eclipse 3.3 only.
So technically it can be done, but what about our users, will you prefer an Eclipse 3.2/WTP 1.5 or Eclipse 3.3/WTP 2.0 based set of JBoss Tools plugins (and as a consequence Red Hat Developer Studio will also be based on Eclipse 3.3/WTP 2.0) ?
There is also the whole issue about checking if the behavior is the same even though the API did not change…
> but hey what can I do when there is no public DOM editor API
File a freakin’ enhancement request to make it public or to have some way to hook into it.
> and previously there where no public java code completion API ?
You see, someone asked for that and everybody have it now!
Eugene – *I* was the reporter and testers of the public code completion API we got for Eclipse 3.2.
And I have voted and reported several issues against the WTP DOM API ever since WTP got release for the first time.
What freakin’ did you expect ?
Correction: I was *one of the* reporters and testers of the public code completion API…
More good bug reports, of course.
go for it: seam + EJB3 + RHDS are all new stuff. People adopting them are making a statement towards new ways to develop. Hence, let’s give’em new tools.
I’d say go for Eclipse 3.3 compatibility. One of the great things about open-source is that you get to upgrade your stuff pretty easily and cheaply to boot. Couple that with the fact that developers (i.e. your target audience) are of the adventurous kind anyway and I think it becomes a no-brainer.
Go with Eclipse-3.3 and WTP-2.0 if RHT has to pick one. Eclipse-3.2 and WTP-1.5 will be put into “maintenance mode” soon enough.
Perhaps have two versions? One for 3.2/1.5 and the other for 3.3/2.0. This only seems feasible if the code for 3.2/1.5 can be generated from the 3.3/2.0-compatible source, and/or the divergence between 3.2/1.5-compatibility and 3.3/2.0-compatibility ends up being quite small.
I think the value in supporting two versions is the greatest upon the launch of JBoss Tools/RHDS proper. As Eclipse-3.2.x and its Web Tools Platform-1.5.x will have the largest degree of market penetration — relative to 3.3/2.0 — at that point in time, which should decrease as time passes. (And JBoss Tools/RHDS itself could be a vigorous driver of 3.3/2.0 adoption.)
But if JBoss Tools requires inquisitive adopters to either scrap their current Eclipse instance, or install a parallel instance, that could be a turn off as well. (This could be ameliorated by offering a “ready-mix” version of JBT for download, as was common while the old-school JBossIDE had regular releases.) Plus, JBoss Tools could risk being a Europa-only “island” if the rest of the Eclipse-plugin ecosystem takes its sweet time moving from Callisto to Europa.
That said, I concur with JS above, Europa will certainly have Teh Shiny(tm) factor, as will RHMW’s tooling offerings. It also gives JBoss Tools/Red Hat Developer Studio (RHDS) a competitive advantage over offerings from other firms.
Maintaining compability would be a pain because of suttle changes in some of the API we depend on – It could be done technically but would require a massive amount of extra testing ;(
With respect to a full single easy to use download then that is what Red Hat Developer Studio will provide.
Remember that when Eclipse 3.3 comes out there will be one single download of it make the installation much easier and then adding our plugins should become a breeze (especially with the update site)
“[W]hen Eclipse 3.3 comes out there will be one single download of it make the installation much easier”
I didn’t know that. Cool! Then by all means, 3.3/2.0-only. If 3.2/1.5 compatibility is required, then the community can backport. (And yes, I know this is a lame “catch-all” excuse.)