However, you do have the power to separate your code into build, runtime, and test stuff simply by adding an extra source set. For example, the grails-x plugin adds a “plugin” source set in which you can add build related code, in particular a Gradle plugin implementation. Just put the code in an src/plugin directory and away you go. In this case, the grails-x plugin will load your plugin code and execute, but the classes won’t be included in the project’s compile or runtime classpaths.

In other words, it’s possible, but you have to manage the classpaths and class loading yourself at the moment.

@Mark Grabbing the Gradle dependency stuff without simply using the whole of Gradle would, I suspect, have been too much work for little reward. I don’t know for sure, but Gradle’s dependency management is probably tightly integrated into its execution model and API. That said, I’m not sure if anyone looked closely at it as a potential solution.

Thanks all for the positive feedback. Glad I’m not a hermit with crazy ideas just yet

Would be great to be able to use a build system for grails with the power to go beyond the “convention” defaults provided by grails. In particular a properly configurable dependency resolution system as provided by gradle….

Not sure why Grails 1.2 did not use the Gradle dependency stuff and implemented it’s own DSL (based on gradle’s one, but a lot less powerful).

Will follow this with great interest.

Mark

great stuff, keep it going.

What I would like to see is the ability to compile source files, which can be used in the scripts provided by Grails plugins. The current build system does not distinguish between build-related code (other than scripts) and application code.

Regards,

Wolfgang