I feel your pain regarding the M2 stuff. Incidentally I did manage to post an article on my blog regarding the old Groovy plugin for M2 shortly after I wrote the M2-Ant-Groovy-compile docs you linked to above. That support worked relatively well until I hit a snag myself. I’m happy to be bailed out with the more recent Groovy M2 plugin submitted by Jason. Good luck getting your groove on and keep spreading the good news! By the way, even though JRuby is planning M2 plugins and IDE integration I’d still advocate the Groovy stuff because it just fits the Java ecosystem better overall.

Thanks for the info, it sounds like your Groovy experiment is going well. One of the commenters to HLS’s post linked above (relating to Tapestry 5 and Groovy) also mentioned using Groovy with Struts 2. Do you know if this is a common choice?

I may give Groovy another try in the near future, with tempered expectations as to interoperability within a single project module. The Spring support for Groovy looks very nice, but I’m not sure if I’m ready to implement my service or DAO layers with Groovy yet

As far as the XML, I estimated it at 50 in my last paragraph, so the 41 may be accurate. However, if you are in fact using the Ant task via Maven, as I was, I’d encourage you to check out the new Maven 2 plugin, which looks much less verbose and was just released a couple of days ago.

You’ve experienced some of the things I have getting started with Groovy. I haven’t run into the closure issue on hashCode and equals. (Don’t ask me why, ok?)

I understand your issue with Java code depending on Groovy code. The compilation order is an issue. There are some methods of working with it though.

1. Interfaces: Have your domain entities implement interfaces that are written in Java. Then your domain entity clients can just depend on the interfaces.

2. Use a maven sub-project for your domain model. Then you can just code away in Groovy on the domain mode, and package it into a jar file. Your other code can depend on that artifact. This would overcome the compilation order issue, and at the same time make your domain model a releasable artifact.

I’m in the process of implementing a project using Groovy for my Struts 2 actions, service beans, and DAO’s. I haven’t done my domain model, because I implemented it using JPA annotations. It would be a lot of work to redo in XML files.

My experience with Groovy has been really good to date. So much so that I made a Struts 2 plugin to instantiate my action classes on the fly, with reload on change to the source file. I’ve also started using Spring reloadable scripted beans too. This allows me to set up my interfaces for a process in Java, then code away in Groovy without needing to restart my application server. (Details on my site.)

As to the Maven and plugin to run groovyc… is your config really 100 lines? Mine is 41 lines, and that has two life cycle hooks in it, to compile and test-compile.

Take care,

Mark