-
Notifications
You must be signed in to change notification settings - Fork 35
Choosing Your Build Tool
Keegan Witt edited this page Jul 9, 2024
·
57 revisions
The goal of this page is to help a developer understand the differences between build tools, as it applies to Groovy integration. It is meant to be unbiased, not an "us vs them" marketing page. Feel free to correct any errors.
Pros
- Maintained by Groovy team, updated at the same time as Groovy releases
- Supports invokedynamic
- Available for all Groovy versions
- You can use pretty much the same setup from your Ant projects in Maven via the AntRun Plugin
- Allows generation of API docs without stubs
- Lets you specify the version of Groovy to use
- Allows Groovy configuration options to be passed to the compiler
- Supports configuration scripts
- Uses Groovy's compilation APIs underneath
- Can write build in Groovy with Gant
- Supports Groovydoc generation (by groovdoc task)
Cons
- It's Ant, so there's more configuration and less convention than either of the Maven options (which may or may not be what you want)
- Uses stubs for mixed compilation
- If you're using the AntRun plugin on a mixed Groovy/Java project, you'll need to have javac handle you Java instead of the Maven Compiler Plugin
- Doesn't support Groovy mojos, except through Java 5 annotations
- Doesn't support execution of Groovy scripts
- Doesn't support interactive shell/console on your project
Pros
- Tighter integration with Maven paradigm than groovyc
- Supports invokedynamic
- Has been around longer than GMavenPlus
- Supports execution of Groovy scripts
- Allows Groovy configuration options to be passed to the compiler
- Uses Groovy's compilation APIs underneath (with the exception of stub generation,which was forked to preserve the Javadoc for use with Maven mojos)
- You can run Groovy tools (like GroovyConsole, GroovyShell, etc) without any additional installation or configuration
- Supports Groovy mojos (although you can't use versions of Groovy newer than 1.6 for this)
- Supports interactive shell/console on your project
Cons
- No longer maintained
- Doesn't support Groovy versions newer than 2.0.x
- Doesn't allow generation of API docs without stubs
- Doesn't let you specify the version of Groovy to use
- Doesn't support configuration scripts
- Uses stubs for mixed compilation
- Not a standard compiler plugin
GMaven 2 isn't a build tool, it only lets you run Groovy scripts as part of your Maven build. As such, many of the pros/cons don't apply.
Pros
- Uses reflection to access Groovy APIs, so except for new features (e.g. invokedynamic), you can use newer versions of Groovy without waiting for a new release
- Tighter integration with Maven paradigm than groovyc
- Supports invokedynamic
- Allows generation of API docs without stubs
- Source code is smaller and simpler than GMaven
- Lets you specify the version of Groovy to use
- Supports execution of Groovy scripts
- Allows Groovy configuration options to be passed to the compiler
- Supports configuration scripts
- Uses Groovy's compilation APIs underneath
- Supports interactive shell/console on your project
- Supports Groovydoc generation
Cons
- Uses stubs for mixed compilation
- Doesn't support versions of Groovy older than 1.5
- Doesn't support Groovy mojos, except through Java 5 annotations
- Not a standard compiler plugin
Pros
- Doesn't use stubs for mixed compilation
- Tight integration with Eclipse
- Is a standard compiler plugin
Cons
- Doesn't support invokedynamic
- Doesn't let you specify version of Groovy to use
- Doesn't support API docs generation
- Doesn't support execution of Groovy scripts
- Doesn't allow Groovy configuration options to be passed to the compiler (because it's a standard compiler plugin)
- Doesn't support configuration scripts
- Cannot choose between Eclipse compiler and standard Java compiler
- Sometimes lags a bit behind new Groovy releases
- Uses forked versions of Groovy's compilation APIs (while these do have some improvements over the standard APIs, it also means no other tool compiles exactly the same as Groovy-Eclipse and occasionally results differ from other tools)
- Doesn't support versions of Groovy older than 1.7
- Doesn't support Groovy mojos, except through Java 5 annotations
- Doesn't support interactive shell/console on your project
- Doesn't support Groovydoc generation
Pros
- Uses the Groovyc Ant task underneath, so should have good compatibility
- Supports invokedynamic (presumably, since uses Ant underneath)
- Supports configuration scripts (presumably, since uses Ant underneath)
- Supports all Groovy versions
- Lets you specify the version of Groovy to use
- Some may like the syntax better than other options (it's a Ruby DSL)
- Supports Groovydoc generation (presumably, since uses Ant underneath)
Cons
- Doesn't support Groovy mojos, except through Java 5 annotations
- Doesn't support interactive shell/console on your project
- Doesn't support execution of Groovy scripts
Pros
- Uses the Groovyc Ant task underneath, so should have good compatibility
- Supports invokedynamic
- Supports configuration scripts
- Supports execution of Groovy scripts
- Can write build in Groovy
- Increasingly popular in the Groovy community (Groovy itself is built with Gradle)
- Supports Groovydoc generation
- Supports interactive shell bound to your project, either through defining your own task (as mentioned in GRADLE-2880), or with the new gradle-groovysh-plugin.
Cons
- Doesn't support Groovy mojos, except through Java 5 annotations
While on the topic of other build tools, I'd like to extend a special thanks to the authors of the GMaven and groovyc projects. Your work greatly increased my understanding of the Groovy tools classes and saved me loads of time. Thank you.