JAX London 2014: A retrospective
Making Groovy-Eclipse 'Groovier'!

What’s New in Groovy-Eclipse 2.5.0?

Jessica Thornsby

“We are grateful that we have strong community involvement in Groovy-Eclipse. It is helping to keep the project moving forward.”

  • Andrew Eisenberg

    Andrew Eisenberg is the lead of the Groovy-Eclipse project and also works on the Grails tooling portion of the SpringSource Tool Suite. Andrew creates IDE tools that ease the cognitive burden of creating complex programs. He will not rest and not be happy until programming is as fun and easy as playing with legos. Andrew has a PhD in Computer Science from the University of British Columbia where he researched the intersection between programming languages and tools.

The Groovy-Eclipse team have just released version 2.5.0. In this interview, JAXenter speaks to Groovy-Eclipse project lead Andrew Eisenberg, about the latest updates, the challenges the Groovy-Eclipse team have faced, and the upcoming 2.5.1 final release, currently scheduled for the end of June.

JAXenter: How does the DSL descriptor support introduced in Groovy-Eclipse 2.5.0, help users of Groovy DSLs?

Andrew Eisenberg: Groovy DSLs are used in nearly all Groovy libraries as well as throughout the core GDK. Until now, only a very few of these DSLs were explicitly supported inside of Groovy-Eclipse. In order to get content assist, navigation support, searching, and other editing support for these DSLs, there had to be hand-crafted extensions of Groovy-Eclipse using Eclipse plugin APIs. For this reason, relatively few have been supported until now.

Since 2.5.0, Groovy-Eclipse supports DSL descriptors (DSLDs), allowing all users to create their own editing support for custom DSLs through Groovy scripting. There is already a DSLD available for Griffon and Gaelyk is coming soon. DSLDs for these frameworks have been created by the community, and this shows one of the strengths of this feature. Since anyone can create DSLDs, we can expect contributions not only from library designers, but from end users as well. The end result is a more intelligent editor and a much better experience for end users.

JAXenter: How has the outline view been improved for the 2.5.0 release?

Andrew: In this release of Groovy-Eclipse, the outline view for scripts has become “Groovier”. Prior to 2.5.0, the outline view for a script file simply showed a dummy class, a couple of methods and a few constructors, none of which actually existed in the source code. This outline was generated directly from the Eclipse Java model of the script, and this may have been confusing for some users.

With the release of 2.5.0, however, the outline view now shows some internal Groovy structure in scripts. The Eclipse Java model has been discarded and instead script variable and method declarations are shown. And this provides a much nicer way to navigate through your scripts.

This feature was submitted as a patch from the community. The JSpresso team wanted to ensure that they could have programmatic control over the outline view so that they could display their DSL in a domain specific way. And so, they submitted this patch. We are grateful that we have strong community involvement in Groovy-Eclipse. It is helping to keep the project
moving forward.

JAXenter: What has been the most challenging task, in making Groovy-Eclipse?

Andrew: The biggest challenge so far has been making the Eclipse Java Development Tools (JDT) aware of non-Java source code (in this case, Groovy). The JDT is a wonderfully architected compiler and toolset that has been designed specifically and only for Java development. Neither the compiler, nor the tools (refactoring, searching, content assist, …) were designed to be a polyglot (i.e., work on more than one language.)

We solved the basic integration problem about two years ago with the initial release of Groovy-Eclipse 2.0.0. In that release, we shipped a patched JDT compiler and a patched Groovy compiler that together was able to compile both Java code and Groovy code using incremental compilation. An advantage of the patched compiler is that it does not generate Java stubs for Groovy code, the way that joint Groovy/Java projects are compiled on the command line.

Despite this solving the problem at the compiler level, we are still battling with this lack of flexibility in the tools. For example, rename refactoring using JDT expects that all identifiers to rename are identical. However, getter and setter methods in Groovy can be accessed using the property name without the get/set prefix and this breaks the JDT conventions when refactoring. Even though JDT does provide some extensibility in the refactoring framework, it is just not quite extensible in the way that we require. And so, we will need to roll our own solution to this problem.

Working with the JDT team, we have been exploring how to open up the Java Development Tools to be more amenable to other languages, but this is still early work. The major problem we are facing now is how to contribute back some of the Groovy-Eclipse patches for JDT, while still remaining backwards compatible and not break API. A major challenge indeed.

JAXenter: Groovy-Eclipse 2.5.1 final is scheduled for the end of June. What can users expect, from this release?

Andrew: We have some exciting features in the works.

First, we are planning an official release of the groovy-eclipse-compiler plugin for Maven. The maven plugin has been available for a while now, but it has only a rough snapshot version and there is nothing targeting Groovy 1.8. Recently, however, the community has been more vocal about GMaven’s problems with stub generation on joint Groovy/Java projects, which can be arcane and cause tremendous headaches for some users. Since Groovy-Eclipse does not require stubs, it avoids these problems.

We are also planning to release a full UI support for adding dynamic methods and properties to Groovy types, making it even easier to customize type inferencing in the editor. This feature will help avoid annoying underlines when the editor can’t determine type information for a reference, but the user can.

DSLD support will also be improved. We are currently in discussion with IntelliJ to work on commonality between our DSLD support and their GDSL support (a feature similar to ours, that was released a short while ago.)

Additionally, we are planning on some smaller improvements to contents assist, type inferencing, and classpath management. Stay tuned for all of the details.

comments powered by Disqus