About

#About GMavenPlus#

##Why?##

These were some of my goals in creating this project:

• Simplify the project for ease of future maintenance (fewer modules, flatter class hierarchies, fewer dependencies -- I'm a big fan of KISS)
• Don't depend on any particular version of Groovy (to let me play with new Groovy versions without waiting for a new plugin release and reduce the needed maintenance)
• Allow access to GroovyDoc tool through the plugin
• Support for invokedynamic
• Be at least as configurable as the groovyc Ant task

##Why not patch GMaven?##

Both projects use the same classes underneath, as does the Ant groovyc task (these classes are maintained by the Groovy project), but I have a fundamentally different idea about how I want to access the Groovy classes. I feel the plugin should be a lightweight (almost a proxy) means of providing access to the Groovy classes and this was very different than how GMaven works. Plus GMaven 2 is taking a completely different direction and only supporting script execution.

##What's so different?##

The fundamental difference is rather than having a plugin dependency choose the version of groovy, GMavenPlus loads your project's compile time classpath into itself and uses Java's Reflection API to make the calls to Groovy that it needs. This gives you more choice over which version of Groovy you use, and makes less work for me because I won't have to release a new version of the plugin every time a new release of Groovy comes out. This makes the code a little harder to read, but I think the benefits outweigh that cost.

##Why not just use groovyc in the AntRun Plugin?##

You could. I don't think all there's an Ant task for the Execute mojo, but I'm sure you could find a way to make it happen. My objection to this is that while there are some newer build tools out there that have some advantages over Maven, Maven is well-established and has a huge userbase. Whether you love it or hate it, both Maven and Ant are here to stay and deserve first-class support.

##Why not just use the Groovy-Eclipse Compiler Plugin for Maven?##

You could. I lay out some pros and cons of this approach here. My main objections with this approach are

• It forces me to use the Eclipse compiler
• It's not nearly as lightweight as I think it should be (this leads to occasional delays after a new Groovy release before I can start using it)
• Doesn't let me choose the version of Groovy I want to compile with
• Doesn't yet support invokedynamic

I feel strongly enough about these issues that I feel the community deserves another choice.