The Groovy-Eclipse team is proud to announce the release of Groovy-Eclipse 2.6.1. Since this is the first release since Grails 2.0 has been available, we have made Groovy 1.8 the default compiler in Groovy-Eclipse. Also, we have started releasing snapshots of our 4.2-based Groovy-Eclipse.
You can use the following update sites to install this release:
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:
Inferring type of overloaded operators
Groovy-Eclipse will now correctly infer the types of overloaded binary and unary operators. For example, in the following screenshot, you can see that val is inferred to be a member of the Tree class. This is because the inferencing engine has determined that the + operation is overloaded and has a return type of Tree:
Also, inside of DSLD scripts, method contributions can be used to overload an operator in an editor. Something like this script would have the same effect as above:
Better inferencing of list and map literals
Groovy-Eclipse now uses more precise techniques to infer the types of list and map literals. Previously, the types of list and map literals were determined by the static type of the first element of the collection. Now, as you can see in the screenshot below, Groovy-Eclipse uses the inferred types of the list and map elements to build the type of the collection:
Code select and inferencing for static imports
We have done significant work around supporting static imports. References to static imports now allow navigation, static imports are now appropriately renamed during refactoring, and they are found during search.
Quick fixes and quick assists
Quick fixes and quick assists are available in the editor by pressing CTRL+1 (or CMD+1 on Mac OSX). Groovy-Eclipse has introduced several new quick fixes and quick assists in 2.6.1.
Move Package and change package declaration quick fixes
Groovy-Eclipse now shows quick fixes for invalid package declarations. When hovering over an error marker for an invalid package declaration, there are two quick fixes available: move compilation unit, and change package declaration. See below for an example:
The behavior is identical to the quick fixes of the same name available in the Java editor. Moving the compilation unit will not only move the file, but also update all appropriate references to the package. Changing the package declaration, will simply change the text at the beginning of the file so that it matches its current directory.
Convert to closure now available from refactoring menu
The Convert to closure and Convert to method quick assists are now available from the context menu under the Groovy Refactor section:
The keybindings are Alt-G F and ALT-G M respectively.
Split assignment/declaration quickfix
The split assignment and split declaration quickfixes are available on any assignment or declaration expression and works like this:
Swap operands quickfix
The swap operands quickfix reorders the left and right sides of binary expressions. This code:
Full Javadoc capability for inferencing suggestions and DSLDs
It is now possible to use Javadoc tags inside of inferencing suggestions. In the inferencing suggestion window (available from Preferences -> Groovy -> Inferencing Suggestions, or from a quick assist in the editor CTRL+1), you can insert full Javadoc comments inside of the Doc text bos.
Which gets displayed in hovers as this:
Similarly, you can use Javadoc tags inside of
Hover and navigation in constructors with named arguments
It is now possible to hover over and navigate to field references used as named parameters in default constructor invocations:
Better content assist for missing methods
Content assist inside of a class body shows all overridable methods. This has been available since Groovy 2.0. Now, we have improved this support and the resulting content assist text will appropriately include argument names and types, will organize imports, and add a doc stub inside the method body if configured to do so.
For example, this:
Editor option to turn off highlighting for dollar slashy strings
Groovy 1.8 introduced dollar slashy strings (link) that allow the specification of multi-line strings like this:
$/ … /$. However, some users found problems with files that made heavy use of regular expressions. For example, in this file the space between the $/ and /$ is incorrectly interprested as a multi-line string:
It is now possible to disable slashy strings by going to the Preferences --> Groovy -> Editor preferences page:
And the file is now highlighted correctly (the underlines are expected).
You must close and re-open files before this change comes into effect.
Per-project script folders
Groovy-Eclipse now allows the specifcation of script folders on a per-project basis. You can control script folders in the Groovy Compiler project properties page:
When clicking on “Enable project specific settings”, the script folder settings for an individual project overrides the workspace settings.
Script folders describe locations in your project that contain Groovy scripts. Groovy scripts should not be compiled into .class files and they may or may not be copied to the oputput folder.
Groovy-Eclipse 2.6.0 includes Groovy 1.8.6 by default. Groovy 1.7.10 can be enabled optionally. This version of Groovy-Eclipse is recommended to be installed on STS 2.9.0, Eclipse 3.7.2. There is also a 4.2-based Groovy-Eclipse now available. See above for the update site.
We have fixed over 100 bugs for this release. See the details on our issue tracker.
We are tentatively planning a 2.7.0 release in June. 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!