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.

  • 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 to Rob Bygrave Cancel reply

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

Related Blog Posts
An Exploration in Rust: Musings From a Java/C++ Developer
Why Rust? It’s fast (runtime performance) It’s small (binary size) It’s safe (no memory leaks) It’s modern (build system, language features, etc) When Is It Worth It? Embedded systems (where it is implied that interpreted […]
Getting Started with CSS Container Queries
For as long as I’ve been working full-time on the front-end, I’ve heard about the promise of container queries and their potential to solve the majority of our responsive web design needs. And, for as […]
Simple improvements to making decisions in teams
Software development teams need to make a lot of decisions. Functional requirements, non-functional requirements, user experience, API contracts, tech stack, architecture, database schemas, cloud providers, deployment strategy, test strategy, security, and the list goes on. […]
JavaScript Bundle Optimization – Polyfills
If you are lucky enough to only support a small subset of browsers (for example, you are targeting a controlled set of users), feel free to move along. However, if your website is open to […]