At the Gradle Summit conference earlier this year, the Gradle team introduced Gradle Cloud Services alongside version 3.0 of the Gradle build tool. These services “improve build automation effectiveness and productivity by adding new capabilities to the Gradle build tool and offering new insights into how you and your team build software.” The first of these cloud services provides support for build scans.
As defined in the Gradle build scan user manual:
Build scans are an important tool for developing and maintaining Gradle builds. They provide insights into exactly what your builds are doing, helping you identify problems with the build environment, dependencies, performance, and more. They can also help you understand and improve the build more generally, and make collaborating with others easier.
The Build Scan Plugin captures data while a Gradle build runs and transfers that data to the Build Scan Service. This returns a link to that build data as useful information that can be shared with other developers. That information is classified into two categories:
- Environmental information including operating system, Java version, and timezone.
- Build-specific information including plugins, tasks, tests, and dependencies.
Source code and project artifacts, such as JAR files, are not recorded.
Adding a build scan to an existing Gradle project requires adding the following configuration to the build.gradle file:
plugins {
id 'com.gradle.build-scan' version '1.4'
id 'java'
}
buildScan {
licenseAgreementUrl = 'https://gradle.com/terms-of-service'
licenseAgree = 'yes'
}
To initiate a build scan, add the command-line switch, -Dscan, to the build command for the project:
$ gradle build -Dscan
After a simple activation process, build information for the project can be viewed online and shared with other developers via permanent links. This allows developers to collaborate and fix issues faster and evaluate build performance.
Given a project that fails a unit test or has a source code error, the resulting build scan will look like the example shown below:
Conversely, a project that passes all its unit tests and is otherwise successfully built, the resulting build scan will look like the example shown below:
In both examples, information can be interactively viewed. Build times are reported in various sections of the build scan so that performance can also be monitored.
A complete sample project can be found on the GitHub repository.
A number of prominent open-source projects, such as Hibernate, JUnit 5 and Ratpack, are using Gradle build scans when developing their respective projects.
Chris Beams, director of marketing at Gradle, spoke to InfoQ about Gradle, Gradle Cloud Services, and build scans.
InfoQ: What is your current role at Gradle?
Beams: I direct our marketing efforts here at Gradle Inc. Previously, I was a principal engineer with the Gradle build tool team.
InfoQ: It would appear that Gradle is separating itself from the other build tools, such as Maven, Ant and Pants, with features such as the Gradle daemon, the new Gradle Cloud Services, and build scans. Do you expect the others to follow suit?
Beams: Probably not. The Gradle daemon in particular is the product of years of work and refinement. It's not the sort of "me too" feature that other build tools can easily implement—at least not in a production-ready fashion. Bazel is a notable exception here, as they are based on a client/server model similar to the Gradle daemon.
And Gradle Cloud Services—including build scans—go well beyond the traditional boundaries of build tool features. They're part of what we see as a larger platform for build automation. This kind of platform-building is ambitious stuff, and that means it's relatively unlikely that other build tools will try to follow suit—at least not without the backing of a company dedicated to build automation and willing to make significant bets on it.
InfoQ: What would you say makes Gradle unique over other build tools?
Beams: A number of factors set Gradle apart from other tools, and its feature set is certainly among them. From Gradle's original innovations like incremental builds to brand new killer features like composite builds, we think Gradle comes out very favorably going head-to-head with any other build tool. You can find an exhaustive list of Gradle features—and a comparison of each with Maven—at https://gradle.org/maven_vs_gradle.
Another factor is the increasingly general-purpose nature of the Gradle build tool. Gradle is written in Java and has its roots in building JVM-based projects, but today Gradle supports building projects across a variety of languages and ecosystems including C, C++ and Android. Adding to this list, LinkedIn recently contributed support for building Python projects with their PyGradle plugin. Becoming the first truly general-purpose build tool is important to us, because it means that language communities of all shapes and sizes—including those that don't yet exist—can move faster by using Gradle as a foundation for advanced build automation and avoiding the need to roll their own.
Gradle also compares favorably with other tools when it comes to adoption rates. We've seen steady increases in Gradle downloads since the project's inception, and we currently average around 2.5 million Gradle distribution downloads per month. There are many thousands of Gradle-built projects on GitHub, and—thanks to the recent availability of the GitHub Archive—we now know that Gradle is the most popular choice among new JVM-based projects there. The Gradle plugin ecosystem is thriving too; there are over a thousand plugins in the Gradle Plugin Portal today, and this means that there's a plugin for virtually anything you need to integrate with or do.
And it's not just the sheer volume of downloads, projects and users that we're proud of. It's also the fact that some of the most admired tech companies in the world have chosen to adopt Gradle—often in a very public way. Consider Netflix's impressive Nebula collection of Gradle plugins, LinkedIn's frequent conference talks on Gradle, or Google's adoption of Gradle as the build tool for Android. One of the reasons these shops have chosen Gradle is another one of its distinguishing characteristics: extreme flexibility. Gradle can go the distance with these shops' very challenging build automation requirements, because Gradle embraces the idea that builds are code too—no different, fundamentally, than any other part of a software product or service you're building. Indeed, Gradle is, among other things, a library and framework for automating the production of software.
Finally, it's important to keep in mind that Gradle is backed by a well-funded company focused entirely on build automation. This means being able to employ more than 30 engineers to focus every day on making Gradle the best it can be. Most other tools don't have that advantage, and it naturally limits how much they can accomplish over time.
InfoQ: With projects, such as Hibernate and JUnit 5, using Gradle build scans, do you expect other well-known open-source projects to adopt build scans for development?
Beams: We’ll see! We’re excited to see how the whole community reacts to build scans, be they open source project maintainers or users. The great thing about build scans is that anyone can create one at any time, and share it with anybody. We think public build scans are handy in all the same places where users would otherwise need to explain what they’re trying to do with Gradle, say on Stack Overflow or in a GitHub issue description or in a conversation with a colleague. Everyone is welcome to take build scans for a spin, and the build scan user manual at a great place to get started.
We’re also excited about the interest we’ve seen in Gradle Enterprise, which is the on-premises version of Gradle Cloud Services. It provides with everything available in the public Build Scan Service along with additional management features that make a big difference—especially for larger teams. Readers can learn more at https://gradle.com/enterprise.
InfoQ: What’s on the horizon for Gradle?
Beams: 2016 was a productive year for us, including getting Gradle Cloud Services off the ground, introducing support for composite builds, and making big progress in improving build performance for projects of all sizes.
But we’re even more excited for what’s coming in 2017. One noteworthy effort is a portfolio of standalone, task-focused guides that will help users new and old find the best ways to solve build automation problems with Gradle.
And we’re going to continue our work toward maximizing build performance on a number of fronts. Early in the year, we’ll announce the first release of Gradle’s task output cache—support for cross-build, cross-machine caches that store intermediate build artifacts and make them available for reuse in any other build—on any other machine—that needs it. We’re already seeing this advanced caching support making a big difference in our engagements with the some of the biggest technology shops in the world; we can hardly wait to get it into general availability!
We’ll also release support for automated separation of library API and implementation artifacts for Gradle-managed dependencies. This separation will enable yet further build performance increases by avoiding unnecessary compilation of a library’s consumer when that library producer’s API (or ABI to be precise) has not changed.
Early 2017 will also see the release of version 1.0 of Gradle Script Kotlin, providing a type-safe and extremely IDE-friendly approach to writing Gradle build scripts.
There’s even more in store, too, but I’ll leave it there for now. Thanks so much for the opportunity to discuss!
Chris Beams is the director of marketing at Gradle Inc., and a practiced open source tool developer. Prior to his work with Gradle, he was a member of the Spring Framework development team.