Groovy-Eclipse and AJDT simultaneous releases

Today, we have just release Groovy-Eclipse 2.1.2 and AJDT 2.1.2. By coincidence, they both have the same version number.

Groovy-Eclipse

We've made lots of improvements to Groovy-Eclipse including inline renaming support, mark/find occurrences as you type, and type inferencing improvements. You can find all the details at the New and Noteworthy page.

The update site for installation on Eclipse 3.6 is here:

http://dist.springsource.org/milestone/GRECLIPSE/e3.6/

We are also now releasing a Groovy-Eclipse for Eclipse 3.7 (Indigo). The update site is here:

http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.7/

As always, please raise bug reports and enhancement requests at our Codehaus issue tracker.

We expect to release Groovy 1.8 support shortly.

AJDT

Our enhancements for AJDT have mostly centered around supporting Intertype Inner Types. a new AspectJ language feature. You can read about it at the AJDT New and Noteworthy.

An AJDT release for Eclipse 3.7 is available at this update site:

download.eclipse.org/tools/ajdt/37/dev/update/

Please raise bugs and feature requests at Eclipse's bugzilla.

eGit in practice

I like Git in theory. Distributed version control has many advantages over non-distributed including local branching, easier task switching, and easier offline work.  However, as an Eclipse user, I find it highly disruptive to drop down to the command line whenever I need to perform any git commands.  Despite its advantages, using git instead of CVS or SVN has felt like a big step backward because of its lack of Eclipse tooling.

Until now, I have only been using git occasionally, and so I could live with the inconvenience.  However, it looks like some of my major projects will be moving to git and so I need to figure out what to do.  I have been eagerly awaiting the eGit tooling to reach a reasonable level of maturity.  I decided to try it out and see how far along it is.

Install and setup

I installed eGit 0.11.3 from the public repository (http://download.eclipse.org/egit/updates) into my SpringSource Tool Suite.  And as expected, the Git Repository perspective was initially empty.  So far so good.

I thought I'd start by cloning the SpringIDE project.  Initially, I tried right clicking in the Git repositories view, and expected that I'd be able to pasted the repository URL directly.  That didn't work.  There is only one option: to paste an existing repository path:

Instead, I used the "clone repositories" command button.  I was able to do what I wanted to, but it was slightly less intuitive than I would have hoped.

Using eGit

After cloning, Git placed the entire repository on my hard drive, which is nice because checking out, exploring, and comparing is much faster than using a traditional VCS.  Performing these operations within Eclipse is just as speedy as doing things like comparing local history.  At this point, I was very impressed.

Then I made a single change to a file and things started going downhill.  After the change, I had to wait about 30 seconds for the '>' to appear in the package explorer next to the changed file (whereas with Subversive and the CVS tooling, this happens what seems like instantaneously):

Then I started playing around... I right-clicked on the file I had just changed and selected Assume unchanged.  Uh-oh!  ClassCastException.  Now, click Assume changed.  IOException.  Apparently, though something worked and I was able to continue with the commit and then view the commit in history.

Next problem: I moved back to the Git Repositories perspective, and I had lost all of the git repositories in the git repositories view.  Re-importing them would not work.  It looked more like the UI had crashed than any data had been lost:

I restarted Eclipse and everything seemed back to normal:

Despite its problems, eGit has a good UI.  The project is clearly following the Eclipse User Interface Guidelines, and I was able to easily transfer my familiarity with Eclipse's CVS and SVN tools to working with git.  This is a strong indicator to me that the project is headed in the right direction even if it is not quite there yet.

And so...

The basic features that I need exist, but after 20 minutes of using, I hit several obstacles.  None of them were insurmountable and the project is usable.  Despite this, I do expect that future releases will be significantly more solid.  I will likely be using eGit for my day to day work, but for now this will be largely for repository and history exploration, rather than for commit and branch management, which I'll probably use the command line for.

---

EDIT: I raised Bug 339158 and Bug 339159 to track some of the problems I found.

AJDT 2.1.1 Released

I am pleased to announce the release of AJDT 2.1.1. In this release, we have focussed on AspectJ-aware searching and refactoring. This release also includes AspectJ 1.6.10.

Please see the New & Noteworthy for more details, including a list of refactorings that are currently known to work in AspectJ files.

AJDT 2.1.1 will be available in the upcoming SpringSource Tool Suite 2.5.0 release, or you can install it from one of the following update sites:

Eclipse 3.6: http://download.eclipse.org/tools/ajdt/36/update
Eclipse 3.5: http://download.eclipse.org/tools/ajdt/35/update

More on Groovy-Eclipse and Maven

I've had a few requests for the source code for the Groovy-Eclipse integration for maven, as well as a sample project that uses it. You can get both the sample project and groovy-eclipse compiler plugin for maven.

They are packaged as two m2eclipse projects, and it is recommended (although not necessary) to import them into Eclipse to use them.

The groovy-eclipse-compiler project contains the compiler integration. It is a single Java class that calls into the Groovy-enhanced JDT compiler. This maven plugin uses plexus to hook into maven's compiler plugin.

The groovy-eclipse-maven-tests project is a very simple maven project that has a few Groovy and Java classes that interact with each other. If you want to create your own project using the Groovy-Eclipse maven integration, I would recommend starting with this sample project.

Please let me know if you have any problems.

Better debug support for Groovy-Eclipse

A short while ago, I wrote about the new debug support for GSP files inside the SpringSource Tool Suite. What I didn't describe is that this has coincided with enhanced debug support in Groovy-Eclipse.

There are a few tricks that you can do inside of Eclipse to vastly improve your debugging experience. Much of this is now automatically configured for you when you install the latest snapshot of Groovy-Eclipse, available at this update site: http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.6/.

Step filters

The Eclipse Java Development Tools supports the concept of step filters that enable a user to specify regular expressions of type names that should be ignored by the debugger. By this I mean that using any of the step commands (step into, step over, step out of...), the debugger falls through any types that match a filter.

This is particularly useful for stepping through Groovy MOP stack frames, including most stack frames that start org.codehaus.groovy.*, and many of the sun.reflect.* frames as well.

Groovy Eclipse now configures a reasonable set of default step-filters for you. These defaults can be viewed and edited in your Eclipse preferences:

Note that it is still possible to stop at a breakpoint set inside of a filtered type, but the next step-* command will step through to the first unfiltered type.

Show Logical Structure

At runtime, closure parameters are wrapped in groovy.lang.Reference objects. This makes for a bit of an annoyance when debugging and trying to browse variables. Take for example this simplified, but common debugging situation. You are debugging inside of a closure and you are using the variables view to explore the current value of your closure parameter:

Unfortunately as you can see, you have to dig 3 levels deep to see the contents of the list.

Again, Eclipse offers a solution. You can select the Show Logical Structure button . The result is a significantly more concise way to browse your variables:

Groovy-Eclipse has added a custom logical structure for Reference objects so that they are automatically dereferenced inside of the variables view. You can edit existing and add new logical structures in your Java Debug preferences:

Stack frame emphasis

Another common complaint about debugging Groovy code is that the extra stack frames from Groovy's MOP hides the application stack frames from view. As an exercise, try to find the application stack frames in the following code (hint: the name of the script is Script.groovy):

On second thought...don't try.  Groovy-Eclipse automatically greys-out MOP and related stack frames, making it easy to see application stack frames (without actually hiding Groovy magic):

This feature, combined with step filtering above makes stepping through Groovy code significantly more efficient.

By default, Groovy-Eclipse de-emphasizes some of the most common MOP stack frames, but this can be changed in the Eclipse preferences:

What's next?

Two of the most requested debugging features are Groovy-aware hotswapping (so that Groovy code can be edited, compiled, and loaded without needing to restart a debugging session) and a Groovy-aware Display view (so that Groovy snippets can be executed in the context of a paused application).

We've had some success with hotswapping, but more work needs to be done before it can be generally useful. Specifically, we've hit some limitations due to the class files produced by groovyc and are awaiting a fix for GROOVY-4152.

A Groovy-aware display view is something that we need to work on and I hope to have initial support for this for the 2.1.0 release in late October.

Clearly, we have work to do, but the existing debug support provides significant improvements over what was available even a few months ago.

Where are all my stubs?

Update: you must also include a pluginRepositories section. See below for XML snippet.



Update: See here for a sample project and the source code of the compiler integration.




The standard way of compiling joint Groovy-Java code outside of Eclipse has always been through the use of stubs:

1. Generate Java stub files for the Groovy files
2. Compile the Java files using the stubs to compile against
3. Compile the Groovy files

Although this works reasonably well in many situations, there are some complications and problems with this approach, most of which have already been described recently in detail on the groovy-dev mailing list here and here, so I won't go into them in this post.

About a year ago, we introduced Groovy-Eclipse 2.0, which compiles Groovy code by plugging into the JDT compiler and does not need to generate stub files. And as Andy Clement describes, it is possible to run the compiler in batch mode on the command line.

And now, with a little bit of glue code required, I have released a snapshot of the compiler with both ant and maven integration. Although, this is still early work, I do hope that this approach will solve many of the problems that Groovy programmers are having with stub generation. I'll describe below how they both work.

Ant integration for Groovy-Eclipse

Ant integration for the batch compiler is fairly simple.

1. Download the groovy-eclipse-batch-0.5.0.jar from its temporary location.
2. Add this jar to your ~/.ant/lib directory.
3. Once you have that, you need to set the build.compiler property to org.codehaus.groovy.eclipse.ant.GroovyCompilerAdapter.

This will cause ant's javac task to delegate the Groovy-Eclipse compiler for the actual compilation. This means that it is possible to pass any combination of Groovy and Java files to the compiler and most parameters applicable for javac are still available when using the compiler adapter.

A very simple script that uses the Groovy compiler adapter looks like this:

<target name="compile">
  <property name="build.compiler"
           value="org.codehaus.groovy.eclipse.ant.GroovyCompilerAdapter">
  <javac srcdir="src" destdir="bin"/>
</target>

This script sets compiler adapter and compiles all source files in src, placing the resulting class files in bin. Both *.java files and *.groovy files are included in the compilation.

Maven integration for Groovy-Eclipse

Groovy-Eclipse can now also be used from maven. To do so, add the following to your pom.xml.

The artifacts are currently in the SpringSource snapshot maven repo. You must add it as a regular repository:

<repositories>
  <repository>
  <id>springsource</id>
  <url>http://maven.springframework.org/snapshot</url>
  <releases><enabled>true</enabled></releases>
  <snapshots><enabled>true</enabled></snapshots>
  </repository>
</repositories>

as well as a plugin repository:

<pluginRepositories>
  <pluginRepository>
  <id>springsource</id>
  <url>http://maven.springframework.org/snapshot</url>
  </pluginRepository>
</pluginRepositories>

And in your plugin section, you must change the compiler used by the maven-compiler-plugin. Like the javac ant task, the maven-compiler-plugin does not actually compile, but rather delegates the compilation to a different artifact:

<build>
...
<plugins>
  <plugin>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>2.3.1</version>
    <configuration>
      <compilerId>groovy-eclipse-compiler</compilerId>
      <verbose>true</verbose>
    </configuration>
    <dependencies>
      <dependency>
        <groupId>org.codehaus.groovy</groupId>
        <artifactId>groovy-eclipse-compiler</artifactId>
        <version>0.0.1-SNAPSHOT</version>
      </dependency>
    </dependencies>
  </plugin>
  ...
</plugins>
</build>

This will allow Groovy files to be compiled. The maven-compiler-plugin prefers all source files to be in src/main/java and src/test/java, but if you prefer you can use the standard Groovy convention and keep your files in src/main/groovy and src/test/groovy. You can do so by adding the following plugin to your build section of the pom:

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>build-helper-maven-plugin</artifactId>
  <version>1.5</version>
  <executions>
    <execution>
      <id>add-source</id>
      <phase>generate-sources</phase>
      <goals>
        <goal>add-source</goal>
      </goals>
      <configuration>
        <sources>
          src/main/groovy
          src/test/groovy
        </sources> 
      </configuration>
    </execution>
  </executions>
</plugin>

This approach is still in an alpha state and has not been widely tested. It was hard to find reasonably large Groovy-Java projects that use maven for me to try this on. The largest project I have compiled in this way is the GPars project (GPars uses gradle for its build, but I adapted its build.gradle to a pom.xml and successfully ran maven on it). This project includes 168 Java and Groovy files in main as well as 338 Groovy files in test. In a not particularly scientific manner, I did a few runs of building the main and test classes using both Groovy-Eclipse and GMaven and the results are that Groovy-Eclipse is reasonably faster than GMaven for this project:

• Time to compile main and test classes using GMaven: 36s
• Time to compile main and test classes using Groovy-Eclipse: 28s

In addition to being largely untested in the wild, there are a few caveats when using Groovy-Eclipse:

• Since stubs are not generated, GroovyDoc and any other artifacts that rely on stubs cannot be generated.
• This only supports Groovy 1.7.
• Third (ant only), your project must have at least one Java file in it (this can be an empty stub), or else ant will finish without compiling anything. There is a patch for this (Bug 48829), but I am waiting for it to be contributed back to ant.
• Fourth (maven only), your maven project must have at least one groovy file or else compilation will not occur. (Though, if your project doesn't have any Groovy files, then why are you using a Groovy compiler?)

There is still some work to be done, but it is ready enough for people to start trying it out. Feedback is greatly appreciated. You can reply to this blog post, send a message to the mailing list, or raise an issue on jira.

Debuggable GSPs in SpringSource Tool Suite

A basic trick of Groovy Server Page debugging that seasoned Grails developers know is that by adding ?showSource=true to a URL for any of your GSPs you can view the Groovy translation of your GSP code.  For example, the vanilla create GSP (http://localhost:8080/TripPlanner/trip/create.gsp) gets rendered like this in the browser:

And altering the URL to this: http://localhost:8080/TripPlanner/trip/create.gsp?showSource=true, you can see the translated source:

There is a mapping between lines of code of the original GSP and the lines of code of the Groovy translation.  In fact, if you are using Grails 1.3.4 or above, and scroll to the bottom of the translation, you will see something like this:

 82: @org.codehaus.groovy.grails.web.transform.LineNumber(
  83:  lines = [3, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 3, 6, 6, 6, 7, 7, 8, 8, 9, 9, 9, 9, 9, 10, 10, 10, 11, 13, 13, 13, 13, 13, 13, 14, 14, 14, 14, 14, 17, 17, 18, 18, 19, 19, 20, 21, 23, 23, 23, 23, 25, 25, 26, 35, 35, 35, 35, 37, 37, 37, 39, 39, 39, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1],
  84:  sourceName = "create.gsp"
  85: )
  86: class ___LineNumberPlaceholder { }

This is the line mapping information and each element of the lines array maps a line from the translation (the array index) to a line in the original source code (the value at that index).  This is not particularly useful to humans, but it is to the SpringSource Tool Suite.

Using this information, STS is finally able to provide some debugging support for GSP files.  You can set a breakpoint at a line in your GSP editor, and the debugger will pause at that line when it is reached while rendering the page:

At this point, your GSP can be interacted with like any Groovy file.  For example, you can inspect the current state of variables in your page binding:

And you can execute values in the display view (using Java syntax only for now):

This feature has been fun to implement since it was my first foray into Eclipse's Java debug interface, but I am not sure how useful it is going to be.  Lines in a GSP are not executed sequentially.  Rather, many are executed out of order through closures inside of an invokeTag method call.  Also, I have not completely worked out how to determine if a breakpoint is at a valid location if Grails is not already running.  So, at this point it is possible to set a breakpoint on any blank line, but these breakpoints are only valid if they are set on a line containing a GSP tag or some other kinds of things.

But, I do hope this is useful to you and if you are interested in trying this new feature out, then you can download STS 2.5.0M3 and install the latest version of Grails tool support.  Enjoy!