Eclipse 3.7 support

With the 2.5.1 release, Eclipse 3.7 has become the main development branch. Although we have been releasing 3.7-based versions of Groovy-Eclipse for a while, it has not been our primary release until now. We will continue to support the Eclipse 3.6-based version of Groovy-Eclipse, but it will no longer be the main branch of our development.

groovy-eclipse-compiler for Maven

We have released the groovy-eclipse-compiler for Maven that let's you use the Groovy-Eclipse compiler in your maven projects. This provides a more robust way of compiling mixed Groovy-Java projects with Maven than previous approaches have allowed. See all the documentation at the Groovy-Eclipse compiler plugin for Maven page.

DSL Descriptor enhancements

Most of the DSLD enhancements are centered around sharing DSLD files among multiple projects in the workspace. For those of you unfamiliar with DSLDs, please read the Better DSL Support in Groovy-Eclipse blog post.

Groovy DSL Support classpath container

All Groovy projects will have the Groovy DSL Support classpath container added automatically. No production code is in the classpath container. It is only meant to contain DSLD files. Inside, there are two class folders: global_dsld_support and plugin_dsld_support, described below.

Global DSLDs

The global_dsld_support folder points to ${user.home}/.groovy/greclipse/global_dsld_support. It is meant to contain DSLDs that should be shared amongst all projects in the workspace. You can place any DSLD files here and it will be picked up by Groovy-Eclipse. Actually, it's not that easy...because of Eclipse Bug 346928, you must go to Preferences -> Groovy -> DSLD and click Recompile before the new scripts will be found:

Plugin DSLDs

The plugin_dsld_support folder points to ${eclipse.home}/plugins/org.codehaus.groovy${active.groovy.version}/plugin_dsld_support. This folder contains the DSLD files that are shipped with this installation of Groovy-Eclipse. Since these files will be changed and updated on each upgrade, it is not recommended that users edit these files.

Controlling the Classpath container

It is possible to manually add and remove the Groovy DSL Support classpath container by clicking on a groovy project and selecting add/remove Groovy DSL Support:

Alternatively, if you do not want the classpath container added automatically to any project, you can disable this in the Eclipse preferences -> Groovy -> DSLD:

Multiple DSLDs of same name

In order to support an eco-system of DSLDs and be able to gracefully handle the conflicts that could occur when multiple versions of a single DSLD exist in a project, Groovy-Eclipse now uses the following heuristics when looking for DSLDs:

All DSLDs with the same name are considered the same, regardless of which folder or jar they are located in.

DSLDs that exist in the project (i.e., not in a jar file and not coming from a binary class folder) take precedence.

After that, the classpath ordering takes precedence. In other words, a DSLD located in a jar at the beginning of the classpath will take precedence over a DSLD located in a jar at the end of the classpath.

If multiple versions of a single DSLD file is located in the project or in a single classpath entry, then an arbitrary one is chosen. The others are ignored.

Disabling DSLD support

It is possible to completely disable DSLD support. You can do this from the preferences -> Groovy -> DSLD page:

Built-in AST transforms recognized in the editor

Groovy-Eclipse now ships with several built-in DSLD files that handle some built-in AST transforms like @Delegate, @Mixin, and @Singleton. Additionally, support exists for Swing Builder. The Groovy DSL Support classpath container must be added to your project in order for this support to be available. For example. here is the singleton transform in use:

And here is swing builder in use:

All hovers over swing builder components have links to full documentation.

What to expect for the future of DSLDs

As we gain more experience with DSLDs, we are learning more about the areas of DSLDs that need improvements. As we make changes to DSLD support, we will try hard to maintain backwards compatibility as well as be clear about which parts of the language have been deprecated. There are a number of things that we will be working on.

Pointcut changes: we are realizing that a number of pointcuts are poorly named and there are others that are ambiguous or superfluous. Expect some changes with the names of available pointcuts. We will try to keep old pointcuts available, but just mark them as deprecated.

Compatibility changes: IntelliJ's GDSLs solve a similar problem that DSLDs solve. However, the syntax is different. We are in discussion with the IntelliJ's Groovy team to see if there is a way of unifying the syntax of the two languages. This is a long-term goal and may not be ready for the 2.5.2 release. This will require some more significant changes to the syntax, but as much as possible, we will try to ensure that the old syntax still works.

Launch configurations

The Groovy Script launcher is now more robust. Upgrading Groovy-Eclipse versions will not break existing launch configurations. Furthermore, these launch configurations can be saved as files in a project and committed into a VCS to be shared between developers.

Compatibility

Groovy-Eclipse 2.5.1 includes Groovy 1.7.10 by default. Groovy 1.8.0 can be optionally installed. Groovy-Eclipse is installable on STS 2.7.0, Eclipse 3.7.0, 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 for the update sites.

Bug fixes

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!