Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

Riding high on the back of the Groovy 1.7 release, the Groovy-Eclipse is pleased to announce its own 2.0.0RC1 release. Over 50 issues have been addressed for this release and we consider this release high quality enough to be considered for release in early January, unless blocking bugs are found.

In this release, we have focused on polishing and refining existing features, but there are some new features introduced as well.

For information about previous Groovy-Eclipse releases, see Groovy-Eclipse 2.0.0M1 New and Noteworthy and Groovy-Eclipse 2.0.0M2 New and Noteworthy.

Better @Grab support

Until recently the use of @Grab to pull in source file dependencies was not recognized by groovy eclipse, resulting in a compilation error for the type that would have been located by following the Grab. Now they are being recognized. The @Grab referenced dependencies are added to the classpath used under the covers to build the project. Content assist is also possible for references to @Grab'd types. Grabbed dependencies are not currently reflected anywhere in the eclipse project metadata (ie. they are not seen in the classpath Eclipse manages for the project) - this may change in a future version of Groovy Eclipse.

When using @Grab, the Grab'd types are available through content assist and unknown references are underlined. In the following screenshot, you can see that the Joda-Time API can be verified and used within the editor even though its jars are only available through @Grab:

Launching Groovy scripts

Launching groovy scripts is now easier and more robust. We have addressed some key bugs in this area: GRECLIPSE-555, GRECLIPSE-560, GRECLIPSE-478.

There is also an option to set the default working directory for the script launcher:

On the Groovy Preferences page, you can toggle between the project root, the workspace root, and the script location.

Additionally, the Run as Groovy Application launch configuration has been removed since it is a complete duplicate of the Java launch configuration. All compiled groovy scripts can be launched as a Java application through its generated main method.

Inferencing improvements

We are continuing to refine the inferencing engine. Some of the notable improvements is support for navigation on the super, and this keywords. Also, content assist will show all the proper method and property completions when the class literal is accessed, e.g.:

And hovers now work correctly for references on super classes, methods, and fields:

Better AST transform support

The AST transform support has been further refined. Eclipse does not allow individual source folders to be tagged as either 'source' or 'test' and then have them compiled separately. Due to this restriction it is hard to support the definition of an AST transform in the same project in which it is consumed. However, Groovy eclipse will allow this to occur if the transform is implemented in pure java (in a .java file) and that transform has no dependencies on uncompiled groovy code (ie. code in .groovy source files in the same project).

Also, groovy eclipse now allows AST transforms to be defined in projects upon which you depend. Previously it only supported consuming them from .jar files on the project classpath.

Jars from .groovy/lib directory added to classpath

All jars in your <user.home>/.groovy/lib directory are added to your classpath as part of the Groovy support classpath container. After a change to the groovy lib directory, you can refresh the workspace's Groovy support classpath container by going to the Groovy Preferences page:

Groovy-aware file copy/rename

Groovy-aware file copy, rename, and paste are working. In the package explorer, you can select a groovy compilation unit and type CTRL-c and CTRL-v (or CMD-c and CMD-v on Mac). The compilation unit will be appropriately copied.

Furthermore, you can rename a class inside of a Groovy compilation unit. To start the refactoring, select a class reference or declaration and select Rename... from the Groovy refactoring menu:

Then the following choice appears:

Choose the Groovy refactoring to rename only the class and it references, but not the file itself. Choose the Java refactoring to rename the file as well as the class. You can then see the standard renaming options from the rename dialog:

After typing the new name and clicking finished, the Groovy class, its file (only if Java refactoring is selected), and all references (both Groovy and Java) are properly renamed:

Navigate to super class

Clicking on an override indicator in the gutter will navigate the caret to the super class's implementation of a method:

JavaDoc viewing

Hovering on a Groovy method field or class will bring up the JavaDoc/GroovyDoc comment for that declaration. For more information, see the Groovy eclipse and javadoc hovers blog post.

Generated getter/setter navigation and JavaDocs

Hovering over a getter or setter generated by a property node will show the JavaDoc/GroovyDoc of the originating field:

And pressing F3 or CTRL-Click when the generated getter or setter is selected will navigate the cursor to the property node's definition (i.e., the field).

Basic content assist options

There are now some basic options to control how content assist proposals are entered into the Groovy editor. You can control whether or not parentheses are used for entering method proposals. And you can also control whether closures arguments are entered with an empty closure { } or as a regular parameter.

Issues fixed

com.atlassian.confluence.macro.MacroExecutionException: The URL filter is not available to you, perhaps it has been deleted or had its permissions changedIf the above doesn't show for you, go directly to the jira issue tracker

  • No labels