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
- Eclipse 3.7.1 and Java 7
- Compiler switching through command line argument
- Enhanced Maven support
- 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
- Bug fixes
- What's next?
Groovy 1.8.2 is now available as an optional install from the update sites.
Eclipse 3.7.1 and Java 7
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
All maven stuff goes here
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. Their position is after all the regular parameters. Finally, 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.
An example should make this clear. Consider the following simple DSLD file that add editing support for the static 'create' method to the Person class:
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) 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 (http://blog.springsource.com/2011/05/08/better-dsl-support-in-groovy-eclipse/) 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)
This version of Groovy-Eclipse 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 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!