Making Groovy-Eclipse 'Groovier'!

What’s New in Groovy-Eclipse 2.5.0?

Jessica Thornsby
What-s-New-in-Groovy-Eclipse-2-5-0

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

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.

Author
Comments
comments powered by Disqus