About
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
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 want 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). Additionally, when Groovy added indy and grooid, it meant GMaven would have needed 3 providers per release or separate plugin releases for each. 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.
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.
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.
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
- Doesn't yet support Android
- Because it uses forked versions of Groovy's classes, it can result in different behavior than groovyc or Gradle
I felt strongly enough about the issues with alternative solutions that I felt the community deserved another choice.