Sword Systems

Say you have a groovy-project that you build with maven.  You use the org.codehaus.gmaven:gmaven-plugin to compile your groovy code and run groovy tests without a problem.  Then you add some features or tests that need groovy 1.7.  You add the proper dependency and version to the <dependencies> section of your pom, run your test… and watch it blow up because the gmaven-plugin defaults to using groovy 1.6.  So you dig around on the web and find references for how to use the <providerSelection> tag of the gmaven-plugin to get your code compiled with 1.7 and to use 1.7 when running tests.  Things seem good.  Until…

You add a feature that requires some version of groovy greater than 1.7.4 (the version included with the latest gmaven-plugin, 1.3).  In my case, I used the @Delegate annotation with some inheritance in a test configuration and hit a bug that was fixed in groovy 1.7.6.  No matter what version I used in my dependencies section, my tests were executed under groovy 1.7.4.  I finally came up with the configuration below which let me run with a different groovy.  Note that it made no difference what I included in the dependencies section.  The gmaven-plugin configuration appears to be completely independent of that.

<plugin>
    <groupId>org.codehaus.gmaven</groupId>
    <artifactId>gmaven-plugin</artifactId>
    <version>1.3</version>
    <configuration>
        <providerSelection>1.7</providerSelection>
        <!-- This is only used if you want to run a groovy script from the command line using maven -->
        <source>${groovy.script}</source>
    </configuration>
    <executions>
        <execution>
            <goals>
                <goal>compile</goal>
                <goal>testCompile</goal>
            </goals>
        </execution>
    </executions>
    <!-- This block is required in order to make the gmaven plugins use a groovy other than 1.7.4.
     This is independent of the groovy entry in the dependencies section.  This does not affect the class path.

     What is interesting is that there must be both the gmaven.runtime entry with the explicit excludes
     and the additional dependency on whatever version we do want to use.  If you exclude the former,
     it will throw an exception. -->
    <dependencies>
        <dependency>
            <groupId>org.codehaus.gmaven.runtime</groupId>
            <artifactId>gmaven-runtime-1.7</artifactId>
            <version>1.3</version>
            <exclusions>
                 <exclusion>
                     <groupId>org.codehaus.groovy</groupId>
                     <artifactId>groovy-all</artifactId>
                 </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>org.codehaus.groovy</groupId>
            <artifactId>groovy-all</artifactId>
            <version>1.7.6</version>
        </dependency>
    </dependencies>
</plugin>

I have been using the Groovy plugin for Eclipse for about 18 months now. First let me say thanks to the team who has put it together. I can’t really complain about any problems since it is a volunteer effort and I haven’t volunteered. And over the time I have used the plugin it has gotten some pretty nice improvements, especially for code refactoring and auto-completion. It’s debugging capability has always been good (with a few quirks). The fact that I can debug scripts as well as regular classes kept me from switching to NetBeans when the major upgrade of that product came out in November without that feature (hmmm… I see there are some upgrades for NB. Yet another thing to add to my to-do list to check out). Overall I find the plugin perfectly capable when writing scripts, especially in small projects. For writing classes however, especially in a large project or when mixed with Java classes, it’s a PITA.

For those that cannot or do not want to move from Eclipse to IDEA or NetBeans, here are a few tips for getting by with the plugin for now:

1) The largest issue is a memory leak. I posted to the groovy user list about it over a year ago. (My explanation of the problem in that post was slightly incorrect. The problem will occur in any project with a lot of classes on the class path, not just one that includes another project.) I think the issue has gotten better in some circumstances, but it still makes it impossible for me to easily integrate groovy classes into my major projects.
Work Around: I have a small “GroovySandbox” project that has the class directory and key required libraries from my main project on its classpath. (Do not include the main project as a dependent project because you will have the exact same memory problem.) I write new scripts and classes in this project and then when they are ready, I copy them into the main project. The memory issue still has an affect, but I can work a full day on groovy files without having to restart eclipse rather than having to restart every 20-30 minutes.

2) Whenever I modify the class path of a project that includes groovy classes (thus triggering a clean build by Eclipse), the groovy class files are wiped with everything else and are not regenerated. I have to go in and touch each groovy class to get it to compile.
Work Around: I now have enough groovy classes that this isn’t feasible, so I created an ant target that compiles only the groovy classes and I trigger it from within Eclipse when necessary. Eclipse detects the newly generated class files and the remaining java classes I have that are dependent on the groovy classes finish compiling. (Why do I have to mix groovy and java so much? See #1, above and #3, below. Unless I want to take advantage of groovy syntax features a lot, I stick with Java.)

3. When I open a groovy class in the editor, it often doesn’t populate the Outline view. Makes it hard to navigate the file.
Work Around: Touch the file, or add-and-delete a space. This was a pain when using CVS for our SCM since the files were tagged as modified, but since switching to Subversion there hasn’t been a problem. I guess Subversion uses something beyond file dates to track mods.

4. When debugging, if I try to step into a class (java or groovy) that is included from another project (which I do frequently since nearly all classes are in the main project due to #1, above), I get an error window saying that the class is part of the Groovy Libraries plugin path and that the path is not modifiable. The screen doesn’t give you a button to modify the source lookup path for the directory/jar. (This one is relatively new. It started happening in some update around the beginning of the year.)
Work Around: Go into the project properties->Java Build Path->Libraries and manually set the “Source Attachment” property for the offending directory/jar. The next time you start the debugger, it will let you step in without a problem.