The Groovy-Eclipse team is proud to announce the release of Groovy-Eclipse 2.5.2. There are many new features available with this release, including Eclipse 3.7.1 support, Java 7 support, and Groovy 1.8.2 support
You can use the following update site 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:
- Groovy 1.8.2
- Java 7 and Eclipse 3.7.1
- Compiler switching through command line argument
- Enhanced Maven support
- User Contributed Inferencing Suggestions
- Inferencing improvements
- DSL Support
- Content assist improvements
- Static type checking (experimental)
- Editing support for Groovy files outside of the build path
- Fix import statements after move/copy
- More precise searching for overloaded methods
- More precise rename refactoring of overloaded methods
- Shout outs
- Bug fixes
- What's next?
Groovy 1.8.2 is now available as an optional install from the update sites.
Java 7 and Eclipse 3.7.1
Groovy-Eclipse now ships with Java 7 compatibility and can install on Eclipse 3.7.1.
Compiler switching through command line argument
It is now possible to use command line arguments to specify a compiler level for Groovy-Eclipse. You can add the
-groovy.compiler.level argument to the launch command to control which compiler level is started.
Enhanced Maven support
Currently, the best version to use is 2.5.2-SNAPSHOT. We will be uploading 2.5.2-01 to Maven central in the next day or so.
groovy-eclipse-compiler plugin for Maven
There have been many improvements to the groovy-eclipse-compiler plugin for Maven. In addition to
Now based off of Groovy 1.8.2 (by default) and 1.7.10 (if specified).
No longer need to use the build helper plugin to specify the
src/test/groovy source folders. They are added to the build automatically if they exist.
Updated groovy-eclipse-compiler archetype project.
Here is a sample pom.xml snippet to use groovy eclipse compiler:
For more information, see Groovy-Eclipse compiler plugin for Maven.
Now works with m2e 1.0 and is also available from the release update site.
User Contributed Inferencing Suggestions
There is now another way to extend Groovy-Eclipse's inferencing engine. Using quick assists and a preferences page, users can now contribute dynamic properties and methods to existing classes for a customized editing experience.
As seen in the image below it is now possible to invoke a Quick-Assist (CTRL-1 or CMD-1 on Mac) in order to invoke the suggestions dialog. In this example, an unresolved property called
getContentDescription in the declaring type
java.util.ArrayList is referenced in a Groovy script. The user then presses CTRL+1 on the editor selection and can add the property via the "Add Groovy suggestion" quick assist.
The Groovy Suggestions dialogue then opens, pre-populated with values related to the current selection, like the declaring type, property name and type.
The user can add additional information like doc hovers, or change the suggestion from a property to a method and add parameters.
Once the dialogue is closed, the suggestion is added to the Groovy inferencing engine and the property will now be resolved. The user can add further suggestions, edit or remove existing ones, in the Preferences -> Groovy -> Inferencing preferences page. Additionally, a user can activate or deactivate a suggestion by clicking a check box. Deactivating a suggestion does not remove the suggestion from the list of suggestions for the project, but any references for that suggestion will be unresolved until the user activates it again.
Suggestions are persisted in the
.groovy/suggestions.xdsl file at the root of all Groovy projects. Each Groovy project has it's own
suggestions.xdsl and so they can be persisted in version control for the project. As of 2.5.2, this feature only supports edits of this file through the preference page or suggestions dialogue. Manual edits of the file are not yet supported.
The suggestions dialogue performs type validation where appropriate, as seen in the following screen shot.
Any suggestions added to a project that are active also appear in content assist, as seen below where getContentDescription appears as an
option in content assist:
We have added many enhancements with the Groovy-Eclipse inferencing engine. A list of all inferencing issues addressed is available here.
Here are the highlights.
Better DGM inferencing
Default Groovy Methods now have better inferencing inside of associated closure blocks. For example, the
unique DGM method now supports inferencing of the parameter on its closure:
In addition to
unique, all methods inside the
DefaultGroovyMethods class now support inferencing on parameters in closures where appropriate. A complete list is available in GRECLIPSE-1143.
Type inferencing of DGM methods with non-collection arguments
Now, when non-collections types are targets of DGM methods, the iterator variable type is correctly inferred:
Other implicit category classes
Support for the implicit category classes
These classes are now handled just like
DefaultGroovyMethods in terms of content assist, hovers, and navigation.
Multiple assignment statements
The types of variables assigned in multi-assignment statements are now discovered during inferencing. For example, when assigning a list to multiple variables, the static type of the list elements will be assigned to each variable:
Also, when a method returns a list or array, the type parameter or component type is used as the type of assigned variabled:
Spread-dot type inferencing
The spread-dot operator is now correctly handled by the inferencing engine:
Match operator inferencing
Match operator expressions now support inferencing:
For more information, see GRECLIPSE-1159.
We are continuing to improve on our DSL support in Groovy-Eclipse through our DSL descriptors. Below are the significant enhancements. And all enhancements are described in more detail in DSL Descriptors for Groovy-Eclipse.
optionalParams for method contributions
It is now possible to distinguish between regular, named, and optional parameters in DSLD method contributions. Regular parameters are always filled in when performing content assist for the method and they are not prefixed by a name. Named parameters are prefixed by a name and are also always filled in during content assist. And they are placed after all the regular parameters. Lastly, optional parameters are not filled in via content assist of the method. Instead, optional parameters are only available for content assist of named parameters. All parameters are visible during hovers.
Here is an example to make this clear. Consider the following simple DSLD file that adds editing support for the static
create method to the
The method contribution defines params, namedParams, and optionalParams. The first thing to see is that when doing content assist, only the regular and named parameters will be shown:
And when applying that proposal, only those parameters are displayed (the first parameter is regular, and the second two are named):
The optional parameters are shown in hovers (along with all other parameters):
They can also be seen in content assist, when named parameters would be visible:
Note that the editor is smart enough to only show parameter proposals if that parameter doesn't already exist, so if we remove the
lastName named parameter and do content assist, it will show up as a proposal:
Content assist improvements
Named parameter content assist
Methods that expect named parameters (typically specified in a DSL descriptor, see above) can have their named parameters filled in via content assist, as shown in this screenshot:
Notice in the screenshot that there are 3 named parameters displayed: firstName, lastName, and age. These are defined in a DSL descriptor in the project.
As with selecting method proposals during content assist, Groovy-Eclipse will try to find reasonable values to fill in when selecting a named parameter:
There is a caveat. Named parameter proposals will not appear in the proposal list if there is a prefix already typed. So, in the following example, there will be no named parameters proposed since the prefix 'f' already exists:
Method context information
Groovy-Eclipse now follows the JDT convention of displaying context information for methods when invoking content assist inside of a method call and there is no prefix. For example, when invoking content assist just after an opening paren, you are only shown a list of known ways to invoke the target method:
Selecting one of the proposals will show that method's information in tooltips above the caret location:
Similarly, invoking content assist after a comma will show context information as well:
For more information, see GRECLIPSE-674.
Content assist now recognizes closure parameters
When a field has a closure for an initializer, content assist will now reflect this and show method proposal variants for the field:
For more information, see GRECLIPSE-1139.
Static type checking (experimental)
Groovy-Eclipse 2.5.2 ships with an experimental way to perform static type checking on your Groovy projects. There is a new menu category that appears whenever any Groovy files, packages, or projects are selected:
When invoking this command, all groovy files currently selected will be type checked (i.e., sent to the inferencing engine). Warning markers are added to any expressions that would be otherwise underlined in the editor:
If you want to remove all of the type check warnings simply select "Remove checks" from the "Groovy Type Checking" menu while selecting the files you want to clean.
You can also add some type assertions to ensure that the static type of an expression is correctly determined by the inferencing engine (this is particularly useful for testing your DSLs):
This feature is still experimental and we are looking for feedback on it. If you find this feature useful, if you have any suggestions for it, or if you have found problems with it, please contact us on mailing list to discuss.
Editing support for Groovy files outside of the build path
Scripts that are not placed on the build path now provide many of the standard editing features that is used by scripts on the build path, such as content assist, type inferencing, and mark occurrences. The classpath for the script is assumed to be the same build path as the one for the rest of the project.
Note that missing import references will not be reported, and references in scripts will not show in search results, nor will refactoring work in these files.
Fix import statements after move/copy
Import statements are now properly cleaned up after a move or copy of a Groovy file to a new location. See GRECLIPSE-682 for more information.
More precise searching for overloaded methods
The number of parameters of method declarations are now used to more precisely determine the actual declaration of a method reference:
See GRECLIPSE-1138 for more information.
More precise rename refactoring of overloaded methods
This new technique for method searching is used to ensure that overloaded methods do not interfere with rename refactoring:
Groovy-Eclipse 2.5.2 includes Groovy 1.7.10 by default. Groovy 1.8.2 can be optionally installed. This version of Groovy-Eclipse is recommended to be installed on STS 2.7.2, 2.8.0.M2, Eclipse 3.7.0, 3.7.1, 3.6.0, 3.6.1, or 3.6.2. There are different update sites for Groovy-Eclipse targeting Eclipse 3.6 and 3.7 (see above).
We've received quite a bit of help with this release from the community, especially with the maven support. So, a special thank you to:
We have fixed over 100 bugs for this release. See the details on our issue tracker.
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!