Skip to end of metadata
Go to start of metadata


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 maintained by the Groovy team underneath (as does the Ant groovyc task), but I had a fundamentally different idea about how I wanted to access the Groovy classes. I felt the plugin should be a lightweight facade, providing access to the Groovy classes without coupling the codebase to a particular Groovy version. This was very different than how GMaven works. It uses a heavier weight Plexus component based implementation, and is compiled against a specific Groovy version, necessitating updating the plugin with a new provider every time a new branch of Groovy was released (sometimes there'd be breaking changes with a minor point release which caused additional issues).  I maintained GMaven for a while, and didn't like the extra work this caused.  GMaven 2 was considering completely different direction and only supporting script execution.

What's so different?

Other than support for additional features, 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.

Why not just use groovyc in the AntRun Plugin?

You could. I don't think all there's an Ant task for the execute, console, and shell goals, but you could probably 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 felt strongly enough about the issues with alternative solutions that I felt the community deserves another choice.

  • No labels