You can use the following update site to install this release.
And a zipped version of the update site is available at:
You can install from the zip by pointing your Eclipse update manager to the downloaded zip file and following the installation instructions.
Snapshot versions targeting Eclipse 3.7 are available. Our 3.7 support is in beta. Although largely working, some functionality may be missing or buggy. You can access the 3.7 update site here:
Typing CTRL-Shift-U (or CMD-Shift-U on Macs) in a Groovy editor when selecting an identifier will search for all occurrences of that identifier:
Above, notice how only references to the
val property are highlighted. Other references with the same name are not highlighted.
If the feature is enabled in your workspace for Java Editors, then when selecting an identifier all references to that identifier will be marked (no need to explicitly press CTRL+Shift+U, but the results will not appear in the search view). The coloring is slightly different from find occurrences, as you can see in the following screenshot:
In the screenshot above, a reference to the
doOperation closure field currently has the carat and the declaration plus all references are selected. This does not affect the previous search results as you can see.
This behavior is similar to that of the Java editor. In fact, mark occurrences in Groovy editors can be configured in the Java Editor mark occurrences preference page:
Note that, the Groovy editor does not support all the variants of mark occurrences that the Java editor does. It is either enabled completely or disabled completely, which is toggled by selecting Mark occurrences of the selected element in the current file.
The Groovy editor now supports inline renaming, just like the Java editor. If the preference is set, all calls to Rename Refactor inside the editor will rename the variables inline:
Deprecated declarations and references are now highlighted with a strikethrough:
Field and method references are highlighted too, if the preference is set:
Method, field, and deprecation highlighting preferences are borrowed from Java and so they can be configured on the Java syntax highlighting page:
Additionally, we have reworked the Groovy Editor preferences page so that there are more syntax highlighting options. Now, it is possible to highlight the
return keyword separately as well as operators:
Yes. Your Groovy editor can now be made to be very pretty. Explore the
Preferences -> Groovy -> Editor preferences page for a full list of what can be changed and more options for customization.
Standard Default Groovy Method calls like
find, etc are recognized by the inferencing engine and their associated closure parameter type is inferred from the type of the collection being iterated over (if it is known). For example, in the following screenshot the collection is of type
List<String>, and so we can infer that the type of
This version of Groovy-Eclipse allows usage of the Groovy++ Ast transforms. Simply grab a version of groovy++ from the Groovy++ project page, for example: groovypp-0.4.170.jar and place the jar on your project classpath. With that in place you can start using static resolution by marking your code with
@Typed. For examples see the Groovy++ documentation.
The Groovy Event Console is available from the console view. To activate it, click on the Open Console button:
Now, interesting Groovy-Eclipse events will be logged to the console view, including information about AST Transforms. Global AST transforms will only be shown if they take more than 0ms to run, to try and reduce unnecessary entries in the console. Please note: the event console is meant for debugging and diagnostics. It may degrade the performance of Groovy-Eclipse if it is open.
The Groovy compiler for Groovy-Eclipse is 1.7.8. We will be releasing 1.8 support shortly.
Suggested types to import in both quick fix and content assist are now ordered based on various criteria so that more common types will be found towards the top of the list. Types imported from
javax.* have higher priority, in that order, than types from other packages as seen in this screen shot where the type
ExtendedList is being imported:
However, if importing types from similarly named packages as well as types declared in the same top level type like a private nested type, the private nested type has higher precedence, followed by public types from similarly named packages, followed by types from
javax.*, and finally types from other packages. The following screen shows the private type
ExtendedList appearing first in the content assist suggestion, followed by a type from a similarly named package, followed by the remaining suggestions:
getAt(String) methods will now be used to feed the inferencing engine when using '[ ]'. For example:
In the preceeding code, notice how the reference to the
name field is correctly resolved to be coming from the MyTree class. The inferencing engine realizes that the use of the '[ ]' corresponds to an invocation of the
Unicode escape sequences (e.g.,
\uE096) now have correct offsets and lengths in the parse tree, so you can use unicode escape sequences freely in your Groovy code and source locations in your file will not be corrupted.
We have made several performance enhancements for the 2.1.2 release, below are the two most notable ones. They primarily target content assist.
Type resolution is now lazier. During code assist we don't actively chase down (resolve) property accessor type references unless necessary.
Where appropriate, the inferencing engine will not visit the entire file to determine the type of a single expression. Rather, it will prune the branches of the AST and only visit the method or field declaration that contains the expression to be inferred. This has a noticeable affect on content assist invocation speeds.
On windows there is now an option to try and avoid Groovy-Eclipse locking jars and preventing them from being updated (or removed, in the case of attempting to uninstall a plugin in a grails project). Specify the system property -Dgreclipse.nonlocking=true when starting Eclipse/STS to activate the use of non locking classloaders. If no problems come up over the next few releases this may be made the default mode of operation. Locks should also be released (regardless of that system property setting) if the offending project is closed.
Those who wish to install Groovy-Eclipse without any UI components can do so from the update site. The feature id is
org.codehaus.groovy.headless.feature. This is primarily useful for those who are performing headless builds using PDE or Buckminster. Note that this feature is uncategorized in the update site, so under normal circumstances you will not see it in Eclipse's Update Manager. However, if you uncheck "Group items by category", you will see the feature.
For more information, see GRECLIPSE-716.
Groovy-Eclipse 2.1.2 includes Groovy 1.7.8 and is installable on STS 2.6.0, Eclipse 3.6.0, 3.6.1, or 3.6.2. Snapshot builds targeting Eclipse 3.7 are available as well. See above for the update site.
Over 50 issues have been fixed for this release.
The 2.2.0 final release is scheduled for the end of June, around the time that Eclipse 3.7 will be released. We will consider a 2.1.3 release that includes Groovy 1.8 support.
We appreciate 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, but we can only do so when we hear from the community.