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 (so it can be as flexible as groovyc and reduce the needed maintenance)
• Allow access to GroovyDoc tool through the plugin
• Support for invokedynamic
• Be at least as configurable as the equivalent Ant task (still ongoing)
• Breathe new life into an abandoned project that I feel is still very important

##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.

##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?##

Again, you could. My main objections with this approach are that it forces me to use the Eclipse compiler, and 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).