Groovy-Eclipse 2.5.2 New and Noteworthy

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:

Groovy-Eclipse update site for Eclipse 3.7 and 3.6 For Eclipse 3.7: http://dist.springsource.org/release/GRECLIPSE/e3.7/ For Eclipse 3.6: http://dist.springsource.org/release/GRECLIPSE/e3.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: http://dist.springsource.org/release/GRECLIPSE/e3.7/XXXXXXXXXXXXX For Eclipse 3.6: http://dist.springsource.org/release/GRECLIPSE/e3.6/XXXXXXXXXXXXX You can install from the zip by pointing your Eclipse update manager to the downloaded zip file and following the installation instructions.

Outline

Groovy 1.8.2

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.

Use -groovy.compiler.level 18 to specify Groovy 1.8 Use -groovy.compiler.level 17 to specify Groovy 1.7 For example, to start Eclipse with a 1.7 compiler: Use '18' to specify the 1.8 compiler.

See Compiler Switching within Groovy-Eclipse and STS-1844 for more information.

Enhanced Maven support

All maven stuff goes here

TODO

User Contributed Inferencing Suggestions

TODO

Inferencing improvements

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:

IMAGE

Other implicit category classes

Support for the implicit category classes DateGroovyMethods, SwingGroovyMethods, XmlGroovyMethods, and ProcessGroovyMethods.
These classes are now handled just like DefaultGroovyMethods in terms of content assist, hovers, and navigation.

For example:

XmlGroovyMethods:

ProcessGroovyMethods:

For more information, see GRECLIPSE-1131, GRECLIPSE-1143, GRECLIPSE-1145, GRECLIPSE-1153, GRECLIPSE-1154 and GRECLIPSE-1155.

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:

For more information, see GRECLIPSE-1140 and GRECLIPSE-1136.

Spread-dot type inferencing

The spread-dot operator is now correctly handled by the inferencing engine:

IMAGE

Match operator inferencing

Match operator expressions now support inferencing:

For more information, see GRECLIPSE-1159.

DSL Support

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.

namedParams and 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 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:

IMAGE

And when applying that proposal, only those parameters are displayed (the first parameter is regular, and the second two are named):

IMAGE

The optional parameters are shown in hovers (along with all other parameters):

IMAGE

They can also be seen in content assist, when named parameters would be visible:

IMAGE

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:

IMAGE

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:

IMAGE

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:

IMAGE

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:

IMAGE

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:

IMAGE

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:

IMAGE

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):

IMAGE

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:

Compatibility

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).

Bug fixes

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

What's next?

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!