Groovy-PDE Redux

Up until recently, doing any PDE work with Groovy has been a bit of a kludge. First, you had to create a customCallBack.xml script. Inside this script you had to call out to a special groovy.jdtcompile ant task, using a magic set of classpath references. When this approach worked, it did so by first compiling your Java code (with errors of course since your groovy code is not touched), and then re-compiling all your code using the joint compiler provided by Groovy-Eclipse.

Not so pretty. It works for Groovy-Eclipse, but that is only because I know exactly what its limitations are and how to work around them.

A short while ago, I wrote about how we re-implemented PDE build for projects that use the AspectJ compiler. I've recently done the same for plugin projects that use Groovy.

Here's how it works:

1. Install the latest dev snapshot of Groovy-Eclipse for Helios (you can write plugins that target Galileo (Eclipse 3.5), but you must use the Helios PDE builder to create the plugins).
2. For each of your plugin projects, add the following to your build.properties file:
   

   sourceFileExtensions=*.java, *.groovy
   compilerAdapter=org.codehaus.groovy.eclipse.ant.GroovyCompilerAdapter
   compilerAdapter.useLog=true  # this ensures that exceptions are logged to the proper log file.

3. Now you can run your PDE export (either headless or from within a running Eclipse using one of the Export wizards).

The only caveat is that each plugin project must contain at least one .java file or else the PDE builder will ignore that plugin. The problem is described in Bug 318951. Before this can be addressed, I need a patch committed to the javac task, described here: Apache Bug 48829 (please vote the bug up if you want to see this fixed!).

With that, creating Groovy-based Eclipse plugins now requires much, much less black magic.

No more handles?

I manage 4 Eclipse PDE builds on two different build servers. Three days ago, I started getting this same exception when running the JUnit tests for all 4 of the builds:

org.eclipse.swt.SWTError: No more handles [gtk_init_check() failed]
 at org.eclipse.swt.SWT.error(SWT.java:3910)
 at org.eclipse.swt.widgets.Display.createDisplay(Display.java:863)
 at org.eclipse.swt.widgets.Display.create(Display.java:851)
 at org.eclipse.swt.graphics.Device.(Device.java:152)
 at org.eclipse.swt.widgets.Display.(Display.java:479)
 at org.eclipse.swt.widgets.Display.(Display.java:470)
 at org.eclipse.ui.internal.Workbench.createDisplay(Workbench.java:532)
 at org.eclipse.ui.PlatformUI.createDisplay(PlatformUI.java:161)
 at org.eclipse.ui.internal.ide.application.IDEApplication.createDisplay(IDEApplication.java:143)
 at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:88)
 at org.eclipse.test.UITestApplication.runApplication(UITestApplication.java:138)
 at org.eclipse.test.UITestApplication.run(UITestApplication.java:60)
...

I was pulling my hair out trying to figure out why all four builds would be failing in the same exact way even though they span Eclipse versions (Galileo and Helios), and servers. All links I could track down seemed to imply that the root cause are SWT resources that are not properly disposed.

It turns out that solution was a bit more banal than that. There were no leaks in my code. Instead, this exception occurred because there was no virtual display available on the build servers for running the UI tests. Xvfb had shut down. After a restart of Xvfb, the tests are now running as expected.

Now, why Xvfb would happen to shut down on both servers at the same time still befuddles me, but the problem is fixed. I just hope that the next person who sees this problem doesn't also immediately think there is a resource leak, and pull their hair out to find it.