OSS Projects Revved Up by Gradle Enterprise

Gradle is proud to support key open-source projects with FREE instances of Gradle Enterprise.

Gradle Enterprise is quickly emerging as a de facto standard tool for build and test data analytics and as a source of acceleration technology for many of the most important open source projects. Here is a roundup of OSS projects that rely on Gradle Enterprise to improve build and test feedback cycle times and make troubleshooting more efficient by combining root cause analysis data with failure analytics. 


Spring is the world’s most popular Java framework for making Java programming quicker, easier, and safer for everybody. Gradle Enterprise is being used by the Spring Boot, Spring Framework, and Spring Security projects. After the Spring Boot project migrated from Maven to the Gradle Build Tool and further optimized the Build Cache effectiveness with Gradle Enterprise, CI builds now take roughly 20 minutes on average, 3-4 times faster than before. Local builds are taking an average of 2.5 minutes, which is 20-30 times faster than before. The team has also started looking at Gradle Enterprise Failure Analytics to address flaky tests and other avoidable failures.

JetBrains Kotlin

JetBrains Kotlin is a general-purpose, free, open source programming language initially designed for the JVM and Android and is the most used programming language for building JVM applications after Java. The JetBrains Kotlin Compiler open source project is built with Gradle Enterprise about 60,000 times every month. Gradle Enterprise was used to reduce median build time from about 10 minutes to about 3.3 minutes. JetBrains made their custom tasks cacheable and also optimized the configuration phase of the build with the help of Build Scan insights. 


JUnit is the most widely used testing framework on the JVM. Given its widespread usage, JUnit needs to be thoroughly tested on all current JDKs and early access versions. Since enabling the Gradle Enterprise remote Build Cache, the average build time decreased by about 50%. Build Scans allow the JUnit team to collaborate on build failures and point out problems in pull requests. In addition, the JUnit team takes advantage of the Gradle Enterprise Test Failure analytics to stabilize flaky tests. More recently, the JUnit build has adopted Gradle Enterprise Test Distribution for CI and local builds to speed up slow integration tests.


Ratpack is a simple, capable, toolkit for creating high performance and scalable web applications built on Java and the Netty event-driven networking engine. It consists of a set of Java libraries for building scalable HTTP applications. Optional Gradle build time support makes building and testing applications a breeze. The Ratpack team relies on Gradle Enterprise Build Scans to efficiently debug build failures and on the remote build cache to accelerate building locally and in their CI pipeline.

Gradle Build Tool

Gradle has emerged as the build tool of choice for projects within the JVM ecosystem, including Kotlin. Gradle Build Tool has a comprehensive automated test suite that covers different operating systems and Java versions. The team runs about 70,000 builds a week. The build relies heavily on the remote Build Cache for build acceleration, Build Scans for finding performance regressions, flaky test management to identify and prioritize fixing the most flaky tests, and Test Distribution to further reduce build times.

Spock is a testing and specification framework for Java and Groovy applications. Spock’s beautiful and highly expressive specification language differentiates it from alternative solutions. Its JUnit runner makes Spock compatible with most IDEs, build tools, and continuous integration servers. Gradle Enterprise surfaced several performance issues in Spock’s Gradle build. Build Scans showed that tasks were not up-to-date with no code changes because of changing snapshot dependencies. The Gradle Enterprise task inputs comparison identified tasks that were not being pulled from the cache. After solving those problems, as well as a few others, Spock’s Gradle build could take full advantage of the Gradle Enterprise remote build cache. This brought CI build times for the Spock project from a median of 3 minutes per build to about 1 minute per build.