Apr 24, 2014

Reuse your Gradle logic across the enterprise

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.

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.

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.

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.

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.

 

About the Author

David Norton profile.

David Norton

Director, Platform Engineering

Passionate about continuous delivery, cloud-native architecture, DevOps, and test-driven development.Passionate about continuous delivery, cloud-native architecture, DevOps, and test-driven development.

  • Experienced in cloud infrastructure technologies such as Terraform, Kubernetes, Docker, AWS, and GCP.
  • Background heavy in enterprise JVM technologies such as Groovy, Spring, Spock, Gradle, JPA, Jenkins.
  • Focus on platform transformation, continuous delivery, building agile teams and high-scale applications.

One thought on “Reuse your Gradle logic across the enterprise

  1. Rob Bygrave says:

    As a variation of Option 2 you can:

    – put all the common gradle files into a git repo
    – clone the git repo to a local directory
    – reference that directory via a property in ~/.gradle/gradle.properties (like: gradle_common=/home/me/gradle_common)

    Then you do:

    apply from: “${gradle_common}/jettyboot.gradle”

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Blog Posts
Explore your Kubernetes cluster with k9s
If you use Kubernetes, you have probably become adept at crafting commands with kubectl (pronounced “koob-cuddle”). Sure, we prefer to interact with the cluster with declarative configs via a deployment pipeline, but sometimes you need […]
Deploying NextJs v9 on Google App Engine
NextJS v9 offers new exciting features like “File system-based dynamic routing” and “Automatic Static Optimization”, but deploying on Google App Engine introduced some new challenges.  In this post I will walk you through the steps. […]
Managing your Helm deployments with Helmfile
As we’ve been using Kubernetes to build software delivery platforms for our clients, we’ve found Helm to be a reasonable solution to templating and managing deployments to Kubernetes.  Although templating alternatives such as Kustomize have […]
AWS CodeBuild Test Reports for Gradle builds
Although AWS documentation has instructions for adding Test Reports for a maven build they currently lack instructions for a gradle build. You can find the maven instructions here: https://aws.amazon.com/blogs/devops/test-reports-with-aws-codebuild/ Assuming you have your gradle wrapper […]