Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

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:

Info
titleGroovy-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:

Info
titleZipped Groovy-Eclipse update site for Eclipse 3.7 and 3.6

For Eclipse 3.7:
http://dist.springsource.org/release/GRECLIPSE/e3.7/archive-2.5.2.xx-20110929-1800-e37.zip

For Eclipse 3.6:
http://dist.springsource.org/release/GRECLIPSE/e3.6/archive-2.5.2.xx-20110929-1700-e36.zip

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

Outline

Table of Contents
maxLevel4
indent20px
styledisc
excludeOutline

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.

Info

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:

Code Block
eclipse -data /my/groovy17/workspace -groovy.compiler.level 17

Use '18' to specify the 1.8 compiler.

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

Enhanced Maven support

We have released, 2.5.2-01 of the groovy-eclipse-compiler. Additionally, the Groovy-Eclipse configurator for m2e v1.0 is now available from the release update site. Full documentation on Groovy-Eclipse's maven support is available at Groovy-Eclipse compiler plugin for Maven.

groovy-eclipse-compiler plugin for Maven

There have been many improvements to the groovy-eclipse-compiler plugin for Maven. In addition to stability and bug fixing, here is what is new and interesting:

  • Now based off of Groovy 1.8.2 (by default) and 1.7.10 (if specified).
  • The Java compiler is now Java 7 based (from Eclipse JDT 3.7.1).
  • No longer need to use the build helper plugin to specify the src/main/groovy and src/test/groovy source folders. They are added to the build automatically if they exist.
  • Updated groovy-eclipse-compiler archetype project. This archetype is available at: https://nexus.codehaus.org/content/repositories/snapshots/
M2E support

Groovy-Eclipse's m2e configurator now works with m2e 1.0 and is also available from the release update site. The old version of the Groovy-Eclipse configurator is still available from the dev update site and we will keep it available for legacy reasons. It is the only version that is compatible with pre 1.0 versions of m2eclipse. However, we recommend against using it if possible.

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:

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:

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:

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:

Code Block
currentType("Person").accept {
     method name:"create", type:"Person", params:[id:Long], 
        namedParams:[firstName:String, lastName:String], 
        optionalParams:[age:Integer], 
        isStatic:true, provider:"Person DSL"
}

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.

Remove trailing whitespace and semi-colons save actions

It is now possible to configure Groovy-Eclipse to automatically remove trailing whitespace and semi-colons on file-save. Go to Preferences -> Groovy -> Save actions to enable it:

It is also necessary to enable save actions for Java editors, which you can do can do by going to Preferences -> Java -> Editor -> Save actions:

Enabling the save action will convert this file:

into this file:

after a save.

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.

Shout outs

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:

  • Travis Schneeberger for work on maven integration, helping to test snapshot versions, and providing suggestions on how to fix bugs.
  • Bob Tiernay for being thorough and checking through all of our type inferencing for DefaultGroovyMethods for anything we missed (and there was a lot).
  • Rene Scheibe for his work on the Save action to remove whitespace and semi-colons.
  • Benson Margulies for helping to migrate the Groovy-Eclipse m2e configurator to support m2e version 1.0. I could not have done this one alone.

And of course, thank you to everyone else who raised bugs on jira and asked questions on the mailing lists.

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!