Roadmap for Groovy Eclipse work

Hello everyone. I know Ed Povazan has not been active, so I will try and step in to fill the void. There has been activity on the Groovy Eclipse development mailing list requesting a roadmap for the future of plugin work. I know that I have been on a soapbox for a while now about how we need full time and paid work to support the plugin, but I think I should take a stab at what I think that the near future of the plugin should be. I think that the current trunk (or what is out on the dev update site) is a viable candidate for a release. I know I have been telling people over the last couple of months to use the updateDev site and not the main release update site. This is not an acceptable circumstance, the dev site is for internal or beta testing only, but the current release version of the plugin leaves me with no option. I know that there may be some refactoring coolness out there and I do not want to discourage progress in any way, but the current version of the plugin on the release site is quite frankly an embarrassment.

So given this state, I propose that we cut a release that includes Groovy 1.5.6 oand represents what is out there on the update development site, so that we can in good conscience tell people to point at the release update site. After the release of Groovy 1.5.7 so that we can accommodate the refactoring, we can include the new stuff and then release it to the development update site for evaluation. This is based on what I understood from the earlier emails that the refactoring work requires Groovy 1.5.7. After a time, a couple of weeks say, if it proves itself stable and ready, then lets push out a version to the main release site. This is relatively standard practice and I see no reason to circumvent it.

This does bring up an interesting point, a couple of years ago it was possible to get new versions of the plugin out quickly because there was a reliable set of beta testers that could give us feedback quickly. Scott Hickey's (the previous Groovy Eclipse lead) team working on a project would download the plugin and put it through its trials and we could find out trouble quickly. It would be interesting to discover if there is anyone out there who could fill this function. As an Eclipse developer, it is amazing how new eyes can find configuration, provisioning, installation and general plugin bugs when you thought everything was fine. This sort of feedback and work is vital.

If we can get regular activity restarted on the plugin (ahem... listening G2One?), I think that releases should occur at regular intervals of between 4 to 6 weeks, in line with common Agile iteration or spring intervals.

If no one has an issue with this, I will go ahead and build a new release and promote it to the main release update site.

As far as a roadmap goes, I had a brief chat with Scott Hickey (the old Groovy Eclipse plugin lead) and I think we came to a simple understanding.

* First, there is some major work that needs to be done under the hood to not have the plugin use the version of the groovy runtime installed in the workbench, but rather use the one that is set for the workspace.

* Second, there needs to be a structure like IJavaElement, or the equivalent, to allow the Groovy Eclipse plugin to support different versions of the Groovy libraries for different projects. The second issue is related to the first issue to some degree.

* Third, there needs to be better integration of the groovy compiler with Eclipse JDT support. I saw an example in the Scala Eclipse plugin where the project has the Eclipse Java nature added to the project, but the Java Builder was not added. This allows the Scala plugin to provide the scala tools to build the class files. I think that something like this should be done for Groovy Eclipse, especially since the groovy compiler will now compile java as well. This will also prevent collisions between the Java builder and the groovy builder.

* Fourth, we need to be chasing the standard that the good folks at IntelliJ have been blazing. The Groovy Eclipse plugin should try and provide most, if not all, the kind of support that IntelliJ is giving to Groovy now. I think what it does for dynamic methods is awesome.

* Fifth, refactoring tools need to be provided that are robust and first class. Hey great job y'all on this one, this kind of work aint easy. I am still intrigued by this notion, because I would love to see good dynamic language refactoring that is more than just grep and replace.

* Sixth, provide at least a basic level of support for Grails development. I know that there has been some work on providing Grails support, but I know it could only be of the very basic sort and there is so much in Grails that screams for IDE support. I mean how cool could it be to get help with writing those GORM domain classes for instance?

* Seventh, enable Eclipse Plugin Development using the Groovy language. This is really more of a personal desire, I think that Grails support or any of the other points I have listed would affect far more people. Still it would be nice to be able to do more and more Groovy Eclipse work in Groovy, right? I think so. As part of this effort we could try to leverage and improve Groovy support for EMF. Heck maybe we could make EMF usable! (*duck*)

* Eighth, as I stated above, if regular work can be restarted on the plugin, there should be regular releases on the order of 4 to 6 weeks apart.

* Ninth, after getting the plugin in a better state, we need to get companies like Genuitech, eBay and other eclipse distribution providers to start including the plugin, if not included by default, at least as an option. I will make a point to get it in to Genuitech's Pulse service.

Most of the points I came up with really were off the cuff, so if you can think of others, please don't keep it to yourself!