The Groovy-Eclipse team is proud to announce the release of Groovy-Eclipse 2.8.0. This is a service refresh of Groovy-Eclipse and it now contains support for the 2.0.7 and 2.1.5 Groovy compilers as well as Eclipse 4.2.

Editor templates

The Groovy editor now supports templating similar to the Java editor. For example, when you invoke content assist, and the prefix matches an available template, you will see it in the content assist menu:

After applying the template, you get a chance to tab through the template variables and edit them:

The list of templates are available in Preferences -> Groovy -> Editor -> Groovy Templates:

Here you can edit existing templates or create new ones:

Surround with...

The Groovy editor now supports surround-with templates. This allows you to surround a selection of code with a template (similar functionality exists in the Java editor). To access this functionality, select some text, and press CMD/CTRL+1:

All the surround-with templates appear as quick fixes. This functionality is also available by Right-click -> Surround with. Or by typing CTRL/CMD+ALT+Z:

Selecting the last line to Configure templates... will open up the template preferences page shown above. All templates that use a ${line_selection} variable will appear in the Surround With menu.

Compiler switching

There are some significant changes in the way multiple compilers are handled in the workspace now. The back end implementation for this has been completely rewritten using different OSGi functionality. From a user's perspective, most functionality should be the same, except for the following differences:

Compiler settings are now per-workspace, instead of per-install. This means that if you use multiple workspaces with different compiler levels, you no longer have to use separate shortcuts to launch them.

There is now a Don't care setting for projects. In the Project Groovy compiler preferences page, you can set your project to Don't care and it will avoid checking for compiler mismatches no matter what compiler level the current workspace is using.

There is now a compiler switching UI. Select a project with a compiler mismatch problem on it. Project -> Groovy -> Fix compiler mismatch problems: Selecting this will bring up the following dialog that allows you to configure all projects throughout the workspace at once:

Navigation and hovers in binary Groovy files

Navigation to definitions and JavaDoc hovers are now supported in class files compiled from Groovy, when the source is available. You can see this here, when exploring the SwingBuilder class:

@DelegatesTo support

In the screenshot above, you can see the Email class and that it is being used as a delegate to the email function. The implementation is snipped, but you can see that when selecting the from field reference inside the closure, its definition is highlighted in the Email class. Also, the hover properly describes where the reference comes from.

Memory improvements

Significant memory improvements are now in Groovy-Eclipse. Here are some numbers. We imported the GPars project into an empty workspace of GGTS 3.2.0 (with Groovy-Eclipse 2.7.2) and also into an empty workspace of GGTS 3.3.0.M2 (with Groovy-Eclipse 2.8.0.M2). We also did the same for an empty Grails 2.2.2 project (i.e., run grails create-app and import the results). After a full clean-compile-clean-compile-GC-GC-GC cycle, you will notice a large difference in heap size:

GPars project

Empty Grails project

STS 3.2.0(Groovy-Eclipse 2.7.2)

348 Mb heap used

130 Mb heap used

STS 3.3.0.M2(Groovy-Eclipse 2.8.0.M2)

133 Mb heap used

108 Mb heap used

Improvement

215 Mb

22 Mb

For compiling GPars, GGTS 3.3.0.M2 has more than 200 Mb smaller footprint. Empty Grails projects show a 22 Mb smaller GGTS footprint. For all the details, see GRECLIPSE-1633. Workspaces that declare enums or annotations in Groovy source will see this dramatic memory improvement. And there are other, smaller tweaks that apply memory improvements to all workspaces.

Better anonymous inner type support

There is now full editor support for anonymous inner types. The outline view works as expected with the inner type appearing properly named and inside of the method that declares it:

Searching for references to methods declared in anonymous inner types works as expected:

And navigation works as expected. Navigating from a method reference will take you to its declaration and navigating from the super-type of the anonymous type will take you to its declaration.

More precise error locations

Error markers now more precisely cover the error that they are describing, specifically with missing type references. As you can see in Groovy-Eclipse 2.8.0, missing types are fully underlined with red squiggles:

And the same class in Groovy-Eclipse 2.7.2 shows that the red squiggles are improperly placed:

Smaller install size

We have repackaged the org.codehaus.groovy bundles and removed extraneous jar files. Install size of Groovy-Eclipse has been reduced by about 20 Mb.

groovy-eclipse-compiler changes

Better formatting of compiler messages

Compiler messages from the groovy-eclipse-compiler are now proper Maven log compiler messages. This means that you can now suppress compiler warnings by using <showWarnings>false</showWarnings> in the configuration of the maven-compiler-plugin.

Now requires explicit groovy-eclipse-batch dependency

The 2.8.0-01 release of the groovy-eclipse-compiler (the Eclipse-based Groovy compiler plugin for Maven) has been released simultaneously with Groovy-Eclipse 2.8.0. The groovy-eclipse-compiler artifact is a small wrapper that implements the compiler plugin API. Actual compilation is delegated to the groovy-eclipse-batch compiler. There is a version of the groovy-eclipse-batch artifact for each Groovy version. Prior to 2.8.0-01, consumers did not need to explicitly specify a groovy-eclipse-batch version in the pom. In this case, the most recent version of groovy-eclipse-batch was used. However, this lead to problems when a new version of groovy-eclipse-batch was released and the behavior of builds would change. Now, the version must be explicit and this ensures stability of builds over time. For example, running with the following will produce an error message:

problematic pom

The error message will look something like this:

And adding a dependency to the maven-compiler-plugin like this, will ensure the compile is successful:

Extra dependency

Compatibility

Groovy compiler

Groovy-Eclipse 2.8.0 uses Groovy 2.0.7 by default and comes with Groovy 1.8.6 can be optionally enbled. Groovy 2.1.5 and 1.7.10 can be installed through the extra compilers section on the Groovy-Eclipse update site.

This is the last release with Groovy 1.7 support. If you want to install Groovy 1.7, then you must de-select Group items by category in the install manager:

Eclipse

This version of Groovy-Eclipse comes pre-installed in the Groovy/Grails Tool Suite version 3.3.0. It is also tested on Eclipse versions 3.7.2, 3.8.2, 4.2.2, and 4.3.

Maven

There are several notable compatibility changes with the 2.8.0-01 release of the groovy-eclipse-compiler: