Groovy & Eclipse: Lead Plugin Developer Speaks
Edward Povazan, project lead of the Groovy Eclipse plugin project and long-time Groovy user, speaks with DZone about the status of the plugin, the planned support for Grails in Eclipse and other future improvements.
Q: Hey Ed, you're the new lead of the Groovy Eclipse plugin project. How did you get involved?
A: I started 2 or so years ago, fixing a few bugs and submitting patches. Soon afterwards I was invited to join the project team.
Q: What's the current state of the project, and what are your plans for the future?
A: GroovyEclipse integrates with Java projects. This means you can edit, run, test Groovy code as well as use any Java code you have in the project. The editor has syntax highlighting, code completion, some code browsing, code outline, etc. There are some quirks, but less and less so. In the last few months there have been numerous contributions that solved class loading issues and code completion bugs. There has been a flurry of contributions recently, including some code completion and code browsing enhancements, code templates.
In the near future all the nice recent patches need to be applied, open but fixed issues need to be closed, and the debugger needs fixing as it does odd things when debugging test cases. I am actually starting on this part now.
Looking further ahead and speaking for myself, I am interested in two things, Grails, and a proper project model. More on Grails later. I would really like a project model to manipulate, much like the JDT. I don't want to reinvent that wheel, so I will experiment a little with the Dynamic Languages Toolkit (DLTK). It's a plugin designed to help add support for dynamic languages to Eclipse. It looks promising in that it maintains a project model, which in turn gives us 'free stuff' such as code search and code browsing. However it opens up the way to more advanced features such as refactoring. Some experiments are needed to see how we can integrate the work done so far with the DLTK.
Q: I heard Scott Hickey say on the Groovy Exchange in London last year that the DLTK wasn't very interesting for groovy since it is meant for language that do not compile to Java byte-code. Do you think some parts may be useful for Groovy?
A: I've spoken with Scott about DLTK a few times, and it's true, they do target dynamic languages that are not typically targeting the JVM. The attraction of DLTK is what we get from the IDE that is generic. Code browsing, outline views with sorting and filtering, searching for references, methods, fields, etc.
However GroovyEclipse is pretty far along, the latest release has JUnit and NUnit integration, code templates, more code completions. So the question is can we use DLTK to fill in some holes more cheaply than implementing new features from scratch?
Q: Do you plan specific support for Grails in the Groovy Eclipse plugin?
A: Yes though there is no concrete plan at this time. I know James has expressed interest in this aspect of the project, he even started on some things a little while back. I'd also like to work on this, as I spend much of my time in Grails code. A major problem at this time is that the team is made up of volunteers, which makes it more difficult to dive into something with intensity and duration, as is possible when working full time on something.
Q: Is there any chance or hope to attract funding for the Groovy Eclipse plugin, particularly for Grails support?
A: I was lucky enough to get paid for the code completion that is in place, so I would think the answer is yes. It needs some planning (putting together a proposal) and asking people who might be, or might know someone, who is interested in funding new features.
Q: What's your favorite feature in the Groovy Eclipse plugin?
A: That is is getting more and more solid and so it 'just works'. I sometimes forget if I am looking at Groovy or Java, and I don't need to do anything special to start using Groovy with an existing Java project.
Q: How and when did you start using Groovy?
A: It was sometime in 2003 - I was looking for a scripting language to use with my day trading tools. At the time I went with Jython as Groovy was still very young and more or less a dream of two guys. It was a dream that became mine, especially when I wanted to extend some Jython classes from Java - with Groovy this is a no brainer. From then on, I started using Groovy wherever I could, first writing tests and then general programming. Now I look at Groovy and Java much as I looked as C and assembler or Java and JNI - Java is for the heavy lifting.
Q: What's your favorite way of using Groovy, or how would you like to use it one day?
A: Can I say everywhere? Specifically, I enjoy creating simple little harnesses that let me interactively solve specific problems. For example, I have a class based on a JFrame that reloads its content when it gains focus. I used this to implement, of all things, some image processing algorithms. It was very productive to edit the image processing code, switch to the JFrame that reloaded the changes and displayed the resulting image, and then to return to my code editor, and repeat.
I wish I could use this kind of programming in general, being able to reload any change while maintaining state. Blame Grails! It's something to experiment with some more. My Utopia is to launch a bare bones app and to implement the rest interactively. Hmm, didn't they do that in the '70s?
Q: What is your primary source for Groovy information?
A: For writing code, Groovy In Action as well as the source code for the Default Groovy Methods, as well as the online docs for both Groovy and Grails. I like DefaultGroovyMethods.java a lot, there are many ideas in there that help, especially early on.
The mailing lists are very helpful too - in my early days using Groovy my questions were always answered by people with deep knowledge of Groovy. It's nice to have the people who are creating Groovy and Grails active in the mailing lists.
Thanks for the interview Ed!
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)