The Groovy-Eclipse team is proud to announce the first milestone release of the Groovy-Eclipse plugin. In this release, we have focused on ensuring that the basic edit-compile-run/test/debug loop works as smoothly as possible. Unlike version 1 of the plugin, this version is based upon a new approach to integrating the groovy compiler into eclipse. We have extended the Eclipse JDT compiler to be pluggable by other compilers for Java-like languages. We have plugged in
groovyc so that the JDT can build and manipulate both Java and Groovy files in the same project (for more information, please read our earlier blog post, A Groovier Eclipse Experience). Importantly, this approach enables incremental compilation to work for a multi-language project. We have also put significant effort into ensuring that Groovy developers can naturally use the same standard Eclipse Java facilities that Java developers have become reliant on. This includes facilities like: JUnit testing, debugging, content assist, early error indication, open-type, and outline views. Full feature details are below.
Cross language dependencies
Full support for any kind of dependency between .java and .groovy files is supported.
Since JDT can now understand groovy source (to a degree), it applies some generics checking to the groovy code and will report correct warnings that
groovyc would not normally show:
Changes made to either .java or .groovy files will result in an incremental compilation of the containing project. Even if the dependencies are in a different language, the impact of the change will correctly propagate.
Projects may exploit AST transforms that are accessible on the project classpath. Transforms like
@Singleton that are defined by groovy are immediately accessible due to the groovy libraries being on every groovy project classpath. To exploit transforms provided by third parties, the jars containing the transform implementation must be added to the project classpath prior to usage. As a temporary feature (still under evaluation) in this version, transforms defined in .java files may be exploited in the same project they are defined, although on changing the transform it may be necessary to do a full build of the project to pick up the change.
Compiler level switching
The Groovy-Eclipse plugin M1 ships with both the 1.7-beta2 and 1.6.5 versions of the groovy compiler. Currently, the only way to switch between the two versions is outside of Eclipse. Here is how:
- Shut down Eclipse
- Go to eclipse/configuration/org.eclipse.equinox.simpleconfigurator
- Make a backup copy of bundles.info
- Open bundles.info in a text editor
- Find the line for org.codehaus.groovy_1.7.0 and delete
- Restart eclipse
To re-enable the 1.7 compiler, simply reinstate the backed up copy of bundles.info.
The wizards available mimic their Java counterparts.
New Groovy Project Wizard
The new Groovy project wizard allows you to create an Eclipse project pre-configured with Groovy support:
It supports all of the options available for Java projects:
New Groovy Class Wizard
This wizard creates a new Groovy class, with many of the same options available for the Java Class creation wizard:
New Groovy Test Case Wizard
This wizard assists you in creating a new Groovy JUnit 3 or JUnit 4 test case:
Convert Legacy projects
On startup, you are reminded to convert any legacy groovy projects in your workspace:
If you can decide to permanently dismiss this dialog box, you can still do the conversion from the preference pages:
As much as possible, we try to provide the same kind of behavior in the Groovy editor as you would expect in the Java editor. By default, the editor uses a different set of colors from the Java editor in order to emphasize the difference between the two languages. However, if you prefer standard Java syntax coloring, you can select it on the following preference page:
Additionally, the Groovy editor provides the following capabilities.
Early error indication and reconciling
Errors are highlighted as you type. This functionality is provided by hooking into JDT's reconciling capability:
An additional benefit of reconciling means that content assist proposals that come from files with unsaved changes will appear where expected. In the following example, the
Shape class the definition of the
numberOfSides property has not been saved to disk yet, but it appears in the content assist proposals list of the
Inferencing content assist has been available since earlier versions of the Groovy-Eclipse plugin. We are continuing to improve on this. For M1, we have focused on reliability and availability of content assist. For M2, we will focus on completeness of results. And for the final release, we will work on some performance tuning.
In following example, notice that there are two levels of inferencing happening. The editor correctly determines that
someObject is an
numberOfSides is an
And now, the inferencing engine is able to determine that the type of
someObject is now a
Typing F3, or CTRL-click (CMD-click on Macs) will navigate to the definition of a reference. Navigation hooks into the same inferencing engine being used for content assist. So, pressing F3 on the following:
will open an editor on the declaration:
You can also notice reconciling at work here because the
Shape.groovy has not yet been saved since the
numberOfSides property has been added.
We have introduced some basic search functionality for M1. Currently, search will be able to locate method, field, and type references if they are explicitly typed. Local variable references cannot be found yet. This is a feature that is of primary importance for M2 and will be significantly improved in the coming snapshot builds.
Again, notice the affect of reconciling in that the search results view contains both references to
numberOfSides even though the text has not yet been written to disk.
JUnit Monospace font
There is an option in the Groovy Preferences page to show the JUnit results pane in monospace font:
This is helpful for viewing the results of Spock tests. With monospace font, the results pane is much easier to read:
than it is without:
There are two facets to M1's debug support: launching and debugging.
There are three launch options for your Groovy files and projects:
This is similar to launching Java applications. A main method of a Groovy or Java class is launched and you are provided with options similar to launching a standard Java application:
Actually, this launch configuration is so similar to the Java Application launch configuration that it may disappear in future versions of the plugin. Every launchable class file generated from a Groovy script is a valid Java program. And so, all Groovy scripts should be launchable as a Java application in Eclipse. This is currently possible, but needs some further testing before we can safely remove the Groovy application launch configuration.
This launch configuration launches a *.groovy file as a script. It is identical to running the
groovy command from the command line. This launch configuration does not require class files to execute. Only *.groovy files are necessary. As an example of this,it is possible to explicitly remove a Groovy file from the build:
And from here, it is still possible to execute a groovy script:
This launch configuration allows the use of the
@Grab annotation since scripts do not need to be compilable before they are executed as Groovy Scripts.
This launch configuration allows you to run a groovy shell in the console view. When run from a particular project, all class files in the classpath of the project are available from the groovy prompt. For example, it is possible to run a Groovy shell and execute code in the following manner:
Note that there is a bug on windows where the
groovy> prompt appears twice on each line. See GRECLIPSE-434.
Breakpoints and debugging
The Groovy-Eclipse plugin allows you to set breakpoints on any statement in a Groovy file, including inside closures, by clicking in the gutter bar next to the line where you want the breakpoint to occur:
When launched in debug mode as a Groovy Application or Groovy Script, execution will break when a breakpoint is reached:
When there is ambiguity as to where the breakpoint should be placed, the debugger stops at both locations. As in the previous example, the debugger will stop at the definition of the closure
c as well as whenever closure
c is invoked.
Debugging will even work if there is no class file available for the particular script being debugged. However, there is an extra step on how the debugger finds the source code for the script. When the debugger stops inside a script that does not have a corresponding class file, you will see this kind of editor:
Click on the Edit Source Lookup Path... button and you will see the following dialog:
Click on Add... and the following dialog appears:
Choose Workspace Folder and select the source folder that contains your Groovy script. The end result should look something like this:
Now, the debugger knows how to find source code for scripts without class files. Please note that in future versions of Groovy-Eclipse, we will include functionality to perform this source lookup automatically.
Once a breakpoint is reached, (as in Java code) you can evaluate variables:
This lets you inspect the current state of the program and even look at the Groovy meta-classes and closures accessible in the current scope.
Runtime evaluation of Groovy code
It is also possible to evaluate code snippets from the display view while in a Groovy scope:
Java syntax is required for evaluating code snippets. What this means is that explicit casting of Groovy objects will be necessary for local variables and dynamically typed references.
The Groovy debugging facility supports conditional breakpoints (Java syntax required). To create a conditional breakpoint, right click on the breakpoint definition and select Breakpoint Properties...:
The breakpoint properties dialog appears. Select Enable Condition and enter the condition to break at (again, only Java syntax is available, so it will be necessary to explicitly cast all variable references):
And now the debugger will stop at the defined location only when the condition is evaluated to true!
M1 contains several new refactoring and formatting facilities.
Indentation & Formatting
The Groovy editor will automatically indent poorly indented code on a paste. So, this:
Quick suffix switching
It is simple to convert from a
.java file to a
.groovy file and back using the context menu:
The Groovy editor supports automatic organizing of imports (CTRL-Shift-O or CMD-Shift-O). Or you can set your project to automatically organize on save through the project properties page:
Note that only Remove unused imports, format on save, and indent on save are respected in Groovy editors. All other cleanup options are ignored.
Basic support for Grape and the Grab annotation is included, but the code using the annotation may show a compile error (due to a missing dependency), however it will run as a groovy script:
Issues addressed for M1
We have fixed over 130 issues for this milestone release:com.atlassian.confluence.macro.MacroExecutionException: The URL filter is not available to you, perhaps it has been deleted or had its permissions changed