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!

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.

AJDT 2.1.0 Released

I am pleased to announce the 2.1.0 release of the AspectJ Development Tools for Eclipse.

In addition to including AspectJ 1.6.9, this release includes a number of new features for making intertype declarations (ITDs) first class citizens in the editor. Java search now includes references and declarations of ITDs. Rename refactorings are now ITD-aware. And we have introduced the new pull-out refactoring, that can pull out your Java fields, methods, and constructors into an Aspect and convert them into an intertype declaration (this refactoring is the converse of the push-in refactoring that was introduced in 2.0.0.

AJDT 2.1.0 is available for Eclipse 3.5 and 3.6 from the following update sites:

http://download.eclipse.org/tools/ajdt/36/update

http://download.eclipse.org/tools/ajdt/35/update

For more details on the new features, please see the new and noteworthy.

Vancouver Eclipse Demo Camp 2010

Last night, 31 Eclipse developers from the Vancouver, BC area met up, listened to a few great talks, went for some beers, and had a great time. We had 8 speakers who surprisingly all stayed within their allotted time of 8 minutes (maybe it was a threat of a nerf gun that did it...I don't know). The pace was brisk and we heard lots of good things from lots of great developers from around Vancouver.

This year's Demo camp was sponsored by the Eclipse Foundation, SpringSource (a division of VMWare), and TaskTop.

Mik Kersten, Tasktop, Welcome and Eclipse Ecosystem Overview

Mik Kersten started the evening off with a brief introduction to some new features in the new Helios release. In addition to modernizing SWT to integrate better with Windows 7, and new Mylyn connectors, the most interesting new feature he described was the Eclipse Market Place. In the past, finding new content to install into your Eclipse installation required users to go to an external browser, find a link to an update site, and copy it into your update manager. Now, all this can be done transparently through the market place client from within Eclipse.

Kris De Volder, SpringSource, AspectJ and AJDT

Next up was Kris De Volder, a new colleague of mine that we snatched from the Computer Science Department at the University of British Columbia (UBC). He demoed some of his new work on AJDT, specifically the new Pull-Out refactoring that allows users to pull-out fields and methods from classes and convert them into intertype declarations. This will be available in the upcoming 2.1.0 release of AJDT.

He also demoed the Push-In refactoring, the converse of Pull-Out, which takes existing intertype declarations and pushes them into their target types. This is work that I did a short while ago and is described here.

Emerson Murphy-Hill, UBC, How Are People Using Eclipse?

Emerson showcased some of his research at UBC on how Eclipse is being used, or not used by developers. Some of the most surprising results of his research, in my opinion, are how little all of the various refactorings are used inside of Eclipse. And how the ones that are popular are not the ones that I personally use.

My personal favorites are rename (field, method, type, etc), extract (local, constant, and method), and convert local variable to field. Apparently, not many people use the last one. But (oddly, in my opinion), inline method seems to be quite popular---something I've never used.

David Dossot, MuleSoft, MuleSoft Tool Suite

David gave a brief tour of MuleIDE, which provides tool support for creating and managing your MuleSoft projects in Eclipse. David used MuleIDE to access road work data from the city of Vancouver and built a simple application to determine how many kilometers of roadwork are currently underway in Vancouver. Not bad for 8 minutes!

Alex Bradley, UBC, Source Code History at Your Fingertips

Do you use the "Show annotations" feature of CVS or SVN? I actually didn't know about this. Using "Show anotations" will add gutter markers on lines changed by recent commits to the source repository. Hovering over the annotations will provide extra information.

Alex showed his enhancements to the Java editor, which converted these annotations into semi-transparent overlays that co-exist with the source code. This is work that Alex has done for his master's thesis at UBC. I liked how his enhancements made version changes more explicit in the editor.

Nieraj Sing, SpringSource, Groovy language and Grails Support in the SpringSource Tool Suite

Nieraj is another new colleague of mine at SpringSource. He's a summer student from the University of Victoria. Nieraj showed his recent enhancements of Grails support in the SpringSource Tool Suite. He showed the Grails explorer view, which allows developers to view their Grails projects organized in a way that emphasizes artifacts and structure specific to Grails projects. He also showed his work on the Grails Plugin Manager, which allows developers to view, install, update, and uninstall Grails plugins into their projects.

Luke Evans, Indicee

Luke introduced the CAL programming language, a lazy-functional language developed by him and others when he worked at Business Objects (now SAP). He showed how programmers can use CAL to quickly and easily compose functions to manipulate streams of data in complex ways. It is this language that forms the core of the business reporting tool produced by his company, Indicee.

Bjorn Gustafsson, ProjectKoach

Finally, Bjorn showed ProjectKoach, an RCP application that brings agile planning into Eclipse. He showed how you can create sprints, manage tasks, integrate with version control, and integrate with bug trackers through Mylyn.

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.

Extending Groovy-Eclipse for use with Domain-Specific Languages Part II

A while ago, I wrote an article about how to extend Groovy-Eclipse for domain specific languages. It was always my intention to write a follow-up that included an example project. Thanks to some prodding on the mailing list, here it is, 5 months later. I finally have an example Groovy-Eclipse extension project available.

The code mostly speaks for itself, so if you are interested in how to extend Groovy-Eclipse, first read part I of this article, and then download the example project.

Here is the example plugin project that extends Groovy-Eclipse. Import this plugin into your Eclipse development workspace.

And here is a simple runtime project that uses all of the extensions provided in the plugin project. Import this project into your Eclipse runtime workspace. If you want to create your own project that uses this example, be sure to add the following project nature to your .project file:

org.codehaus.groovy.eclipse.example.nature

Once again, the code speaks for itself, so there is nothing more that I need to say about it. Enjoy!

Vancouver Eclipse Demo Camp 2010

The Vancouver Eclipse DemoCamp is on once again! This year, it is sponsored
by the Eclipse foundation ( http://eclipse.org ), Tasktop Technologies (
http://tasktop.com ), and others (see p.s.).   This June 29 come out and showcase your Eclipse
based products/tools/research to a crowd of local enthusiasts in a casual
environment. If you are interested in giving a short (10min) presentation,
please send us an email and add yourself to the wiki.

Those who just want to stop by for a beer and see what cool new Eclipse
based technology is being developed in your home town, please register by
adding your name to the wiki as well.

Date: June 29th 6:30pm
Location: TBD  (Likely Robson Square as usual)
After party: 8:00 (location TBD)
Keep an eye on the wiki page to see the finalized schedule

Last year, we had a great turnout with over 50 attendees and some amazing
demos.  It's an excellent opportunity to get to know the local Eclipse
community.  Hope to see you there!

Thanks,

Robert (Tasktop) and Andrew (SpringSource, a division of VMWare)

p.s. - In previous years, the event was fully funded by the Eclipse foundation, but
this year (in part, due to the world-wide success of these events), the
foundation no longer has the budget to provide the same level of funding. 
We are therefore looking sponsorship from the community. If your
company would like to foster the Vancouver Eclipse community, provide extra
branding for the event, and a dedicated speaker slot, please contact us. 

Groovy-Eclipse for Helios

Today we released our first snapshot of a Groovy-Eclipse build for Eclipse 3.6 (Helios). We haven't set the continuous build system up yet, so for now if you are looking to try it out, you can download the zip here:

http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.6/groovy-update-site-e36.zip

And then point your p2 installer to the downloaded archive. You will then be able to install Groovy-Eclipse. We have only tested on 3.6 M6 and we will continue to ensure that it works on later milestones as they come out.

As always, your feedback is appreciated!

EDIT (June 30, 2010): the zip above is outdated and so I removed it. Please use the update site below instead:

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

AJDT-PDE builds Redux

AspectJ-aware PDE builds in AJDT have always been a bit of a kludge. So, I'm happy to say that as of Eclipse 3.6 (Helios), things will be changing for the better and AJDT will rely on a different mechanism to perform PDE builds.

PDE, or the Plugin Development Environment, is the tool set that helps developers build plugins for the Eclipse platform itself. In Eclipse 3.5 and earlier, AJDT shipped with its own version of the PDE tools (AJDT-PDE) that were largely a copy of Eclipse's PDE, but with a few key changes so that a different compiler could be plugged in. It is an understatement to say that this was inefficient. The AJDT-PDE had to be re-created for each point release of Eclipse so that it could be re-based off of the new version of PDE. This process was fallible and inevitably, some features of PDE were missing or broken in AJDT-PDE.

I have been working with the PDE team to create a more sustainable solution to AspectJ-aware PDE builds. From AJDT for Eclipse 3.6 and onwards, the AJDT-PDE will be removed. The AspectJ-aware export wizards will be deprecated and the org.eclipse.ajdt.pde.build plugin will be redundant. Instead, users can use the standard PDE build, with the following changes to the build.properties file of your plugin project:

# required
compilerAdapter=org.eclipse.ajdt.core.ant.AJDT_AjcCompilerAdapter
sourceFileExtensions=*.java, *.aj

# optional
compilerArg=-aspectpath other.jar

The first line specifies that the AspectJ compiler should be used instead of the Java compiler. The second line specifies what file types should be considered source files. And optionally, you can specify a number of command line arguments using the compilerArg property. Only AspectJ-specific arguments like inpath and aspectpath need to be specified here. For all standard Java options, like source and target you can use the standard PDE-Java options javacSource and javacTarget.

From here, you can use the standard PDE export wizards or PDE headless build scripts to build your project. That's it. There is now nothing special needed for AspectJ-aware PDE builds.

Furthermore, it is possible to create your own compiler adapter so that you can use your own custom compiler for your own JVM language (and avoid using javac). You need to do the following:

1. Implement org.apache.tools.ant.taskdefs.compilers.CompilerAdapter and delegate to the compiler of your choice


2. Ensure that this new compiler adapter is on the ant classpath. I recommend using a org.eclipse.ant.core.extraClasspathEntries extension point so that your plugin automatically contributes the classpath to Eclipse's ant runtime. But, you could also specify it in your global ant classpath properties page.


3. In your build.properties file, fill in the proper values for the compilerAdapter, the sourceFileExtensions, and the compilerArg properties.
   

That's really all there is to it. For all the gory details on how this works see Bug 303960.

Groovy-Eclipse 2.0.1 Released and see you at EclipseCon!

We are proud to release to announce the release of Groovy-Eclipse 2.0.1. This release is primarily a service refresh of 2.0, but there are a couple of interesting new features including debug stack frame filtering and Eclipse 3.5.2 support. You can read the New and Noteworthy.

The update site for the release is here:

  http://dist.springsource.org/release/GRECLIPSE/e3.5/

This is also a good time to promote my talk at EclipseCon. I will be speaking about Groovy-Eclipse on Wednesday, March 24 at 2pm.

Getting Groovy with Eclipse: Next Generation Tool Support for Dynamic Languages. Come hear how Groovy-Eclipse has extended the JDT compiler to provide deep integration between Groovy and Java. Also hear about how Groovy-Eclipse provides editing support for Groovy's dynamicism through type inferencing.

See you at EclipseCon!

AJDT for Helios now available

Just a quick note to let you know that AJDT targeting Helios (Eclipse 3.6) is now available from the following update site:

  http://download.eclipse.org/tools/ajdt/36/dev/update

AspectJ-aware PDE export facilities are currently broken. I am not planning on fixing it. Instead, I have been working with the PDE team on an alternative solution. See Ability to override javac task during pde builds (Bugzilla). I'll write more about this later, but the solution is much more elegant than what is currently available in AJDT for 3.5 and earlier.

Also, as a bonus, this version includes intertype declaration (ITD) -aware Java search. Finally, ITDs are completely first-class citizens in the workspace. I'll write more about this later, too.

Intertype Declaration support in Java projects

A user recently had a problem with Roo and AspectJ. This particular user had a Roo project being referenced by a regular Java project. Roo is a rapid application development tool for Java. It makes heavy use of AspectJ's Intertype Declarations (ITDs). So, all Roo projects re AspectJ projects. And here is where the problem is. When an AspectJ project makes use of ITDs, Java projects that reference it cannot reference the ITDs without errors. Well actually, the Java projects compile and run correctly, but there are spurious error messages that appear in the editor, and ITDs do not appear in content assist.

A simplified version of this problem is below:



Here, there are two projects, an AspectJ project and a Java project. The AspectJ project has an aspect that declares an ITD on a Java class. This Java class and its ITD is then referenced in the Java project. Even though the Java project compiles and runs correctly, an error appears in the editor.

Thankfully, there is a simple fix to this. Open up the .project file for the Java project and add the following line to the nnatures element:

  <nature>org.eclipse.ajdt.ui.ajnature</nature>

(Note: this line should be the first nature if you want the AJ decorator to appear on the project icon.)

What this does is tell AJDT that this project should be treated like an AspectJ project, but it does not change the compiler, so the Java compiler is still used. The result is that ITDs are now correctly recognized in the editor:



In the future, I'll probably add a quick fix or some other automated way of doing this in future releases of AJDT, but for now this manual process is a reasonable workaround.

Approaches to Extending JDT

As most of you who have already read my blog know, I write a lot about extending Eclipse's Java Development Tools (JDT) for use with Java-like languages such as AspectJ and Groovy. The problem, as I've mentioned before, is that while the JDT is very good at providing tool support for Java in Eclipse, it provides no support for Java-like languages. To date, I've taken two approaches to addressing this problem. Now, there is a third approach, Object Teams, that has recently made a home at Eclipse.

JDT Weaving

With AJDT, the AspectJ development tools, I developed JDT Weaving. This approach uses Equinox Weaving to weave into the JDT plugins. Yes, we are eating our own dog food here and using AspectJ to implement AJDT. But, this approach has worked well for AJDT since AJDT only requires a small number of well-defined hooks into JDT to get its tight integration.

Feature patches

For Groovy-Eclipse, our tool support for the Groovy language, the JDT Weaving approach was not feasible since we needed a larger number of hooks into JDT. And the nature of these hooks made it difficult to use AspectJ to advise them. So, instead we are using a feature patch. This means that Groovy-Eclipse ships its own (slightly modified and heavily tested) version of the JDT core plugin. This also means that Groovy-Eclipse needs to be re-released for each new version of JDT Core (however, this turns out not to be much of a problem since our release cycle is much shorter than JDT's).

Object Teams

Now, Object Teams is a third approach, which I find very exciting (actually, this approach has been around for several years, but it has only recently moved to Eclipse.org). Object Teams is itself an Aspect-Oriented extension to Java, with a component, O/T Equinox, that provides integration with Eclipse's Equinox OSGi framework. O/T Equinox has been further adapted to provide easy extensibility to JDT. The O/T blog has a slick example of this approach. I'm looking forward to exploring this approach more.

So what?

Although it's great that we have been able to get around JDT's shortcomings and there are multiple ways of doing this, but this proliferation of approaches is a little scary. There is no guarantee that these approaches will play nicely with each other. For a while, Eclipse installs with Groovy-Eclipse would break the Scala plugin (the Scala plugin uses a variant of JDT weaving). Although this problem has now been fixed, we need to be especially careful that a similar problem does not happen in the future. Similarly, the Object Teams tool support and Groovy-Eclipse are incompatible because they both ship with feature patches for JDT Core.

Of course, the best solution would be to push our changes into JDT Core itself, we have been unsuccessful as of yet. Until then, we need open communication between all JDT hackers to make sure that we are working towards the same goal.

If you're interested in learning more or have some ideas of your own, come have a chat with me at EclispeCon.