DIY Gradle Plugin Development

Plugging into Gradle Plugins - Part 4


Using Our Plugin

Having introduced that convention object to the plugin (and having “registered” it in the project as shown above), let’s finally take a look at what it would look like to configure a build that uses the Liquibase plugin. This build file defines a single database ChangeLog, plus a single sandbox data- base using the H2 embedded database. It then sets a default workingDatabase, so that all of the tasks introduced by the Liquibase plugin will have a default database to connect to without being explicitly configured (listing 6).

Listing 6

changelogs { 
        main {
                file = file('changelog.groovy') 

databases { 
        sandbox {
                url = 'jdbc:h2:db/local_sandbox;FILE_LOCK=NO' 
                username = 'sa'
                password = "
workingDatabase = databases.sandbox

A real-world build file might need to be more complex than this, but it’s possible for it to be this simple and to remain useful. Hundreds of lines of build code are completely hidden inside the plugin, and advanced functionality introduced to the build tool as a native part of its vocabulary. And that vocabulary itself is expanded to encompass a new domain that isn’t a part of the core build tool itself. This, ultimately, is what plugins are for.


Plugins are an essential part of the real-world use of Gradle. We use the core plugins for common purposes like building Java code and deploying to repositories. We can easily access plugins built by the community, adding functionality and new configuration options to our builds with just a few lines of code. Most importantly, advanced build masters can create their own plugins to perform arbitrary work and extend the language of the Gradle DSL in unique ways. All of this can be done from within a Gradle build file or in a standalone project with its own release history, tests, and deployment automation. With Gradle, developing the build is just like developing software. Plugins deliver on Gradle’s promises of easy extensibility and bringing the full scope of contemporary software development practice back into the build process – where it has belonged all along.


This article first appeared in Java Tech Journal - Gradle from December 2011. To read more of that issue, download it here.

Tim Berglund
Tim Berglund

What do you think?

JAX Magazine - 2014 - 06 Exclucively for iPad users JAX Magazine on Android


Latest opinions