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

Object Partners profile.

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.

Related Blog Posts
Natively Compiled Java on Google App Engine
Google App Engine is a platform-as-a-service product that is marketed as a way to get your applications into the cloud without necessarily knowing all of the infrastructure bits and pieces to do so. Google App […]
Building Better Data Visualization Experiences: Part 2 of 2
If you don't have a Ph.D. in data science, the raw data might be difficult to comprehend. This is where data visualization comes in.
Unleashing Feature Flags onto Kafka Consumers
Feature flags are a tool to strategically enable or disable functionality at runtime. They are often used to drive different user experiences but can also be useful in real-time data systems. In this post, we’ll […]
A security model for developers
Software security is more important than ever, but developing secure applications is more confusing than ever. TLS, mTLS, RBAC, SAML, OAUTH, OWASP, GDPR, SASL, RSA, JWT, cookie, attack vector, DDoS, firewall, VPN, security groups, exploit, […]