DIY Gradle Plugin Development
Plugging into Gradle Plugins
Gradle uses a Groovy-based DSL for its build configuration files. Since Gradle build files are also Groovy scripts, build masters have essentially unlimited flexibility to extend Gradle in whatever ways they want, just by writing Groovy code in the build file. While this kind of power is attractive, and while every Gradle user is likely to sketch some Groovy code into a build at some point, this isn’t a sustainable way to grow the functionality of the build. The only thing worse than a build tool that resists your customizations is one that gives you a blank slate for as much ill-considered, poorly-factored, and untested code as you can write. Gradle has a better way.
Much of the out-of-the-box functionality provided by Gradle is given through the means of Gradle plugins. Building Java code, packaging executable applications, or running code quality analysis through Sonar is as easy as applying a core plugin with a single line of code. Knowing these plugins is an essential part of using Gradle for ordinary builds, and they are well-documented in the Gradle User Guide that comes with every release.
But what happens when your needs outgrow the functionality of the core plugins? What happens when you, like any other build master building real applications, need to write code to do things the creators of Gradle couldn’t anticipate? When you get to this point, it’s time to write a plugin.
In this article, we’ll enhance Gradle with the ability to manage changes in a relational database. Our goals will be to extend the Gradle DSL with a small new syntax, while keeping imperative Groovy code entirely out of the build.