I posted previously about configuring a Gradle project to ensure that only the indy version of Groovy (that is the variant that supports Java 7’s invokedynamic bytecode instruction) is included in the dependency graph. However, just including that version of the Groovy jar is not enough to make your Groovy code compile in such a way that it uses invokedynamic.
Since version 2.0 the Groovy distribution has included an alternate artifact that enables invoke dynamic support.
I recently started helping with the Ratpack website. It is (or will be) a Ratpack app & built with Gradle. I started prototyping with a simple webapp created with Yeoman and using SASS and Compass for authoring CSS. When I migrated the work-in-progress into the ratpack-site application I initially used Ted Naleid’s method of calling Yeoman’s Grunt tasks from Gradle. Unfortunately this meant there were rather a lot of build dependencies. In order to build the app you would need Node.js, Ruby and the Compass gem installed. Peter Ledbrook pointed out this could frustrate potential contributors & Marcin Erdmann proved an example of what he meant. Clearly I needed to simplify.
There’s a fairly popular technique in Grails plugin development where the plugin has test apps stored in
test/projects/*, each of which references the plugin by including
grails.plugin.location."my-plugin" = "../../.." in its BuildConfig.groovy. Doing this allows you as a plugin developer to:
Automate tests for sample projects using the plugin with significantly different configurations.
Test using domain classes, controllers, etc. that shouldn’t be packaged with the plugin.
Test drive, changing code in both the test app and the plugin without the need to use
grails install-pluginto pick up changes.
The downside is that to run all the plugin project’s tests it’s necessary to run the plugin’s own tests, then change directory into each of the test apps and run their tests. Continuous integration config is also fiddlier for the same reason.