Gradle is a powerful and flexible build tool, not least because you can write custom tasks with ease by inlining your tasks as part of the build script. However, as with production code, build code will sometimes need to be reused across the enterprise. Here are a few ways to do so.

Option 1: Copy and paste?

OK, I said it. I’m not a fan of Copy and Paste Programming, but I also try to be pragmatic about it. If you’re trying to reuse just a few lines of configuration, perhaps its better to simply copy and paste into the other project’s build script.

task config(type: Zip) {
    from file('src/config')
    classifier = 'configuration'
}

artifacts {
    archives config
}

Of course, if you had a bug in that build logic, you’ve now replicated it across multiple projects. That risk grows as you move from configuring built-in Gradle tasks to writing your own custom tasks.

Option 2: Use a shared Gradle build file

If you’d like, you can extract the common elements of your Gradle build files and throw the common build logic on a web server.

apply plugin: 'groovy'
apply from: "http://domain/path/shared.gradle"

//other build logic

task config(type: Zip) {
  from file('src/config')
  classifier = 'configuration'
}

artifacts {
  archives config
}

This has the benefit of simplicity, but the downside that you’ve lost cacheability, version control and other benefits of standard Maven-style dependency management.

Option 3: Gradle plugin

Finally, you can move your build logic into its own project and provide a Gradle plugin as a JAR to any project that needs it. A plugin is not very scary - you can think of it as a bundle of build logic packaged up as a JAR.

apply plugin: 'groovy'

group = 'com.objectpartners'
version = '1.0'

dependencies {
  compile gradleApi()
  compile localGroovy()
}

uploadArchives {
  repositories {
    //we will pretend this is a real Maven repository
    flatDir {
      dirs "/tmp/repo"
    }
  }
}

import org.gradle.api.*
import org.gradle.api.tasks.bundling.Zip

class ConfigurationPlugin implements Plugin<Project> {
  void apply(Project project) {
    project.task('config', type: Zip) {
      from 'src/config'
      classifier = 'configuration'
    }

    project.artifacts {
      archives project.config
    }
  }
}

To use this plugin, you have to set up a dependency on the plugin in the buildscript section of your build script. This adds the plugin to the buildscript’s classpath rather than to the compile classpath.

buildscript {
    repositories {
        flatDir {
            dirs "/tmp/repo"
        }
    }
    dependencies {
        classpath 'com.objectpartners:gradle-config-plugin:1.0'
    }
}

apply plugin: 'groovy'
apply plugin: ConfigurationPlugin

//... other build code

Obviously, this is more difficult to set up and maintain, but it also gives you the benefits of dependency management and a release cycle. Because the plugin is just Groovy code, it is testable.

Speaking of a release cycle, Gradle helps you out here in some ways, and leaves other release tasks to the user. Support for uploading to a Maven repository such as Nexus or Artifactory is built-in to Gradle. However, for an automated release process, you will need to use a plugin. Without it, you will need to manually update your project version each time you want to cut a new release. I personally use this gradle-release plugin, which provides a Maven-like release process. Others may prefer a less-involved release plugin, which bases the version off the branch name.

Have you found yourself reusing Gradle build logic? I’d love to hear from you! Please leave your comments below.