Skip to end of metadata
Go to start of metadata

The Groovy-Eclipse team is proud to announce the release of Groovy-Eclipse 2.6.0. As usual, we have some exciting new features in this release, including quick fixes/quick assists, improved content assist, and improved search and refactoring. Groovy-Eclipse 2.6.0 includes 1.8.4 support as an optional add-on. Once Grails 2.0 is released officially, we will make Groovy 1.8.x the default compiler in Groovy-Eclipse.

You can use the following update site to install this release:

Groovy-Eclipse update site for Eclipse 3.7 and 3.6


If you want the Groovy 1.8 compiler, you must explicitly include it by checking the "Extra compilers" category.

And a zipped version of the update site is available at:

Zipped Groovy-Eclipse update site for Eclipse 3.7 and 3.6


For Eclipse 3.7:

For Eclipse 3.6:

You can install from the zip by pointing your Eclipse update manager to the downloaded zip file and following the installation instructions.


Search and refactoring

Search and refactoring of generated getters, setters, and properties

Groovy-Eclipse now allows you to search for references to generated getters, setters and properties. For example, searching for references to a Groovy property (such as age in this example) will find all references to getAge and setAge in both Java and Groovy files:

Similarly, references Java to getters and setters can be found inside of Groovy files even when they are referenced as properties. In this example, the class Person is defined in Java with explicit getters and setters. Searching for references on setAge will return references to the generated age property in the Groovy

This also works for refactoring. As in the first example, when Person is defined as a Groovy class, we can rename name to fullName and the synthetic getters and setters will be renamed in both Java and Groovy files:

Note that you will sometimes see warnings during refactoring like this:

This warning comes about since some of the synthetic references in Java files cannot be determined to be precise by the Java search engine. By the nature of the language, refactoring of Groovy code can never be as precise as Java code is. It is always recommended to view the preview page before executing a refactoring.

For more information on this feature, see issues GRECLIPSE-1204, GRECLIPSE-1010, and GRECLIPSE-1205.

Better default parameter support

For this release, we have done significant work with searching for and refactoring methods with default parameters. Now, searching for references to a method that has default parameters will locate all references to that method, regardless of how many parameters that reference uses:

Similarly, rename refactor will correctly rename all references no matter how many parameters are used:

For more information on this feature, see issues GRECLIPSE-1255 and GRECLIPSE-1233.

Better extract local variable refactoring

Extract local variable is now more precise as to where the variable is extracted to. Now, the variable is placed in the statement immediately preceding the variable's first use. See this example, where is extracted to a variable and placed inside the enclosing closure.

See issue GRECLIPSE-907.

Parser Recovery

Further recovery enhancements have been made to the Groovy Parser. This enables it to cope better with malformed code and that enables content assist to offer suggestions in more places than before. Here are a couple of examples of the 2.6.0 improvements:

When a trailing close paren is missing

These two situations show that correct content assist options are available even though there is a missing close paren:

When working on if conditions

It is now possible to work on if conditions without the then block {...} being defined

It will even work if the trailing paren of the if condition isn't specified:

Content assist

Suppressing default groovy methods (DGMs) from content assist

It is now possible to selectively suppress DGMs from cluttering content assist. There is a new Preferences -> Groovy -> Content Assist preferences page:

This page contains a list of names of DGMs to be filtered from content assist. You can add and remove names individually by clicking on New... and Remove. Alternatively, you can edit the entire list at once by clicking on Add multiple.... This opens a dialog box with a multi-line text editor where you can easily add and remove multiple entries at once. See here:

As expected, when in the editor, entries that have been suppressed no longer appear in content assist. In this case, each has been filtered, but eachWithIndex has not:

For more information, see issue GRECLIPSE-1182.

Support for named arguments in constructors

When a Groovy class has no explicit constructor, it is possible to build an instance to the class using named arguments as described in Groovy Beans. Groovy-Eclipse now provides content assist support for this kind of constructor call. In the following example code, performing content assist inside of the parens of the constructor call will bring up all remaining available

And, like all parameters applied in content assist, Groovy-Eclipse guesses some likely values for the parameter:

Note: named parameter content assist will only be available if there is no prefix. I.e., it will be available here:

but not here:

(/**/ is the location where content assist is invoked)

For more information, see GRECLIPSE-1228.

Better content assist for methods with closure arguments

When performing content assist on a method and the last parameter is a closure, the proposal will be applied with an opening curly "{", but no closing curly as here:

As a user, you can choose to delete this and add your own content, or you can press enter and the closure will be completed for you:

For more information, see issue GRECLIPSE-1232.

Better content assist in closures

When inside of a closure, methods defined in the enclosing class are now available in content assist (GRECLIPSE-1114):

Similarly, the fields closure and owner are now available in content assist when inside a closure (GRECLIPSE-1267):

Quick fixes and Quick assists

Thanks to some help at a Groovy-Eclipse hackathon, we now have quite a few quick fixes and quick assists. Quick fixes are available based on a particular error marker in the editor. And quick assists are available based on the structure of the syntax tree.

Both quick fixes and quick assists can be invoked by pressing CTRL-1 (or CMD-1 in Mac) on a selection in the editor.

Add unimplemented methods/Make class abstract Quick fixes

When a concrete base class implements an abstract super class with abstract methods, there are two quick fixes available:

  • Make class abstract, which adds the "abstract" modifier to the sub-class
  • Add unimplemented methods, which adds method stubs for all unimplemented methods, as shown here:

Add groovy classpath container Quick fix

When errors like these are seen on the first line of the editor, it means that the Groovy libraries cannot be found:

There is now a quickfix that will automatically add the Groovy classpath container to the project:

Convert to closure and convert to method quick assists

This pair of quick assists can be invoked when inside of a method or closure declaration (the closure declaration must be assigned to a field), and allows a quick conversion between the two.

For example, this method declaration:

is converted into this closure:

And the closure can be converted back into the method declaration.

Convert to single line/multi line string

This pair of quick assists converts between single and multi line strings. When converting between string variants, newlines, tabs, etc are properly (un-)escaped.

Here, a single line string is converted into a multiline string:

And, it can be converted back:

Remove unnecessary semi-colons

This quick fix will remove all unnecessary semi-colons from a Groovy file. For example, this file:

Will have all unnecessary semi-colons removed, but required ones will remain:

Compiler Integration

Groovy 1.8.4 support

Although Groovy-Eclipse still ships with the 1.7.10 compiler by default, 1.8.4 is available as an optional add-on. Groovy-Eclipse always ships with the compiler version that is compatible with the current production release of Grails. Since Grails 2.0 is not available in production yet, we do not ship the Groovy 1.8.x compiler by default.

Better Grab support

Groovy-Eclipse is careful to not allow AST transforms to run during reconciling. Reconciling is the special compile done on the editor contents whilst they are actively being worked on, prior to a save. AST transforms are prevented from running because they can damage source locations/etc that in turn damage other editor features (breaking search/refactoring/etc). However, in 2.6.0 the Grab transformation is being allowed to run since it doesn't modify the code structure but instead just pulls in jars to be on the compilation classpath. This should mean that when working on scripts/etc that are Grab'ing dependencies, there should be no errors in the editor view.

More binary dependencies

The Groovy-Eclipse classpath container now includes the ivy, jline, and bsf jars by default. Even thought these libraries are not typically used directly in user code, including them on the classpath will help with searching for binary references. See GRECLIPSE-1211.

Maven integration

There is now better ordering on the Java classpath of Groovy source folders when importing maven projects that user Groovy into Eclipse and STS. See GRECLIPSE-1222.

Also, we have updated the Groovy-Eclipse compiler plugin for Maven docs to be explicit about how to configure your extra source folders.


Groovy-Eclipse 2.6.0 includes Groovy 1.7.10 by default. Groovy 1.8.4 can be optionally installed. This version of Groovy-Eclipse is recommended to be installed on STS 2.8.1 or 2.9.0.M1, Eclipse 3.7.1 or 3.6.2. There are different update sites for Groovy-Eclipse targeting Eclipse 3.6 and 3.7 (see above).

Bug fixes

We have fixed over 70 bugs for this release. See the details on our issue tracker.

Shout outs

We had a successful Eclipse hackathon this November in Vancouver, B.C. and we received a number of quality patches from external contributors:

Thanks for your work. And of course, thank you to everyone else who contributed in other ways by raising bugs on jira or asking questions on the mailing lists.

What's next?

We are tentatively planning a 2.6.1 release in February. You can take a look at all issues we are planning to fix for this release.

We appreciate all community support and feedback. If you wish to join the discussion about Groovy-Eclipse then please sign up for the mailing list. For any issues you have (or enhancements you would like to see), please raise them in our issue tracker. If there is an existing bug fix or enhancement that you require are not seeing any movement on, please make some noise on it (and get your friends to do the same). We respond to community feedback, and we can make the most improvements to Groovy-Eclipse when we hear directly from the community. So, please speak up!