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!
Wednesday, July 16, 2008
Subscribe to:
Post Comments (Atom)
Posts
12 comments:
What was that comment you made about EMF? You realize of course that where you live is public knowledge, right? So it's best to be careful or someone is liable to reef on your GString and give you a terrible wedgie.
James,
I seconded your motion. I think it is critical that Eclipse have great Groovy and Grails support for its continued adoption and growth. I believe many enterprise developers are required to use Eclipse or an Eclipse based tool so Eclipse must include excellent support.
Well it better be soon, cuz Netbeans is coming on strong with its groovy/grails support in 6.5
But I am a believer.
Sure would be nice if the NetBeans and Eclipse people (for the groovy plugin anyway) could pool resources so that everybody wins.
all of this would be welcome very much. nice to realize, that someone cares about this and takes the lead.
for my department one big reason not to use groovy for critical tasks, is the 'lack of integration with eclipse.
refactorings is on place one of the wish-list.
all the best for your intentions
Thanks for the update. I've been using IntelliJ instead of Eclipse because the Groovy/Grails tooling seems to be lagging behind. I'd love to see Eclipse get up to the latest version of Groovy and smooth out some of the rough edges.
I personally don't see much value in refactoring support in the tooling, but maybe that's just me. The Grails support would be handy, for sure.
As some pie-in-the-sky wishing for features, the one thing that continually irritates me is how the dynamic typing (or whatever you prefer to call it) seems to mean giving up all IDE type support. When I've had to go back and maintain programs that I wrote in Groovy just six months ago, I find I spend much of my time searching through source code to find out just what attributes and methods are on my classes where static languages like Java make it available with a simple ctrl-space. After spending a few months coding in other languages, even trivial details like whether String has .length, .length(), .getLength(), .size or .size() ends up wasting a few minutes. I've never been good at remembering details like this and groovy turns this into a near-critical failing.
In many cases, the variable type can be guessed based on the last assignment; it may not be perfect, but it would be a huge time-saver, much more so than refactoring. It probably won't be a simple or straight-forward feature, but it would be very high on my list. Do you know anyone that's accomplished anything like this with other dynamic languages?
I would LOVE to see some updates to Groovy Eclipse - I prefer to use eclipse when possible and actually have a few problems with IntelliJ, and also I like to have one IDE for all my languages that I program in - Eclipse is very flexible like that. I'd be willing to help test... although I can't say that I'm as quick as most people.
James,
This is great news! It's very essential that somebody keeps user community updated on the latest developments, otherwise only a selected few will be using the plugin and majority of people will ignore it for a while.
I guess - you volunteered yourself for the PR job :)
Third, there needs to be better integration of the groovy compiler with Eclipse JDT support. [...] I think that something like this should be done for Groovy Eclipse, especially since the groovy compiler will now compile java as well.
I do not really understand: Do you want to compile the java files also? I hope this is not the intend.
Or you just want the control over the project and delegate the compilation of single java compile units to JDT? This would be worse enough.
Actually I am thinking about trying to hand over control of all compilation of groovy/java units in a groovy project to groovyc. The reason for this is simple, remove the dueling builders. In particular, it could eliminate the problem we have had with whether to put the groovy builder before or after the java builder. This problem is highlighted by the case where in a single project you have Groovy depending on Java depending on Groovy or vice versa. I have alot of experience with this problem and it is the approach the Scala Eclipse plugin takes.
Rest assured though, any changes like this will be made to simplify things and to make the plugin more robust.
I found that DLTK could help in developing groovy eclipse plugin. Some people think it is not a good idea because DLTK does everything (parsing...) and we have already a groovy compiler. Still i think adaptation could be done in order to use their generic element hierarchy the plugin needs.
Rectenly i found another eclipse project easing the development of langauge ides : SAFARI. It became an eclipse project : IMP. They have currently many interesting components. Sure giving a try (they provide wizards and cheat sheets to create ide)could be quick and nice. Here are some interesting extracts from the overview:
intro:
The Eclipse IMP's purpose is to develop a set of extensible frameworks and exemplary tools built on the Eclipse platform that ease the creation of IDEs for programming languages (new or otherwise) that do not yet enjoy full-featured Eclipse support. Our ultimate goal is to assist language implementers in creating IDEs with a richness and usability on par with the Eclipse Java Development Toolkit (JDT). In the near term, however, we intend to provide support for a significant portion (but not all) of the JDT's functionality.
related projects:
The DLTK is a related effort, but requires the use of a specific AST class hierarchy to drive much of its functionality, which is not suitable for arbitrary languages, nor for situations in which a compiler front-end already exists. Nevertheless, we intend to investigate what portions of the DLTK's infrastructure can be reused or adapted.
Thank you and keep up the good work!
Post a Comment