JCenter shutdown impact on Gradle builds

On February 3 2021, JFrog announced that they will be shutting down Bintray and JCenter. This post tells you what you need to know and do to avoid disruptions to your build pipelines.

Your build may be affected by this shutdown in several ways:

Additionally, you should be aware of the security considerations when moving from one repository to another.

UPDATE: JFrog has decided to keep JCenter as a read-only...

❯ Read more

Introducing the Gradle Fellowship Program

Community is instrumental to the success of every open-source project. At Gradle, we are very fortunate to serve and collaborate with an amazing community of users, champions, and plugin authors.

Some of the community members go above and beyond to help other users succeed. We are extremely grateful for their dedication. Their valuable contributions to the community include helping others on the Gradle Forums and Community Slack, publishing blog posts and presenting at conferences and user groups.

We are excited to introduce the Gradle Fellowship program to recognize and connect those individuals and grow this global community of Gradle experts to help the broader Gradle community be more productive.

We’ll support the Gradle Fellows in their efforts by offering additional...

❯ Read more

Gradle vs Bazel for JVM Projects


Gradle has emerged as the build tool of choice for projects within the JVM ecosystem, including Kotlin. It is the most popular build...

❯ Read more

Refining the Gradle issue backlog

One of the biggest success factors of Gradle is its community. There is no day that goes by without users suggesting new features, finding and reproducing defects or opening a pull request with a contribution. We appreciate every single issue that users create. Thank you!

Working on a successful project like Gradle comes with challenges, be it the number of questions and contributions or deciding which aspect has the highest priority for the team. Even though we don’t like to accept it, we don’t have infinite capacity. We want our teams to be able to focus on producing the most value for our users. That means fixing the right bugs and implementing the best features. Given the diversity of our community, this...

❯ Read more

What’s new in Gradle 6.0

Gradle 6.0 is the culmination of several years of innovative improvements in Dependency Management. Embracing the idea that there is more to software composition and reuse than just putting a set of jar files on the classpath, Gradle now offers a new metadata format to richly define software components that are often made up of multiple files, different variants and specific constraints on their dependencies.

In particular, in this webcast Developer Advocate Jenn Strater and Gradle Engineer Jendrik Johannes discuss:

  1. What’s New in Dependency Management
  2. Java, Groovy, and Scala toolchain improvements
  3. New features for plugin authors

You can access the slides of the...

❯ Read more

Using build scan tags for ad-hoc root cause analysis

Recently I was helping an Android team investigate a hard-to-reproduce issue that manifested as very-long-running compilation and annotation processing tasks. Most of their builds took only a few minutes to run, but sometimes they took up to 30 minutes! In these cases, invariably, a build scan showed that some combination of Java compilation, Kotlin compilation, or annotation processing with Kapt, was the culprit. The team had no real idea of how often this problem occurred for developers, and under what conditions.

Gradle Enterprise does not, yet, provide a way to find builds based on how long a particular task took. However, custom tags make it easy to categorize and find builds for any condition that can be detected within a build. By...

❯ Read more

What’s new in Gradle 5.0

A lot has changed for Gradle since version 4.0 was released in mid-2017.

Gradle 5.0 is much faster and more memory efficient than previous versions of Gradle, has better tools to inspect and manage transitive dependencies, and can provide the IDE assistance you’d always hoped and expected through a new Kotlin DSL.

This 1-hour webcast demonstrates 4 key themes of Gradle 5.0:

What Gradle’s Kotlin DSL does and who should adopt it How to take full advantage of incremental compilation and annotation processing Why unexpected dependency version X was selected and how to fix it What new task APIs are available in Gradle 5.0 If you prefer just the info, check out this page on the highlights of Gradle 5.0 and...

❯ Read more

Gradle Plugin Portal Approval Policy Update

Gradle is updating the plugin approval policy for plugins submitted to the Gradle Plugin Portal, effective today, to begin adding stronger security safeguards for plugin consumers.

First off, this does not affect plugins already on the plugin portal, just new plugins. Gradle builds that use plugins will not be affected in any way.

Portal acceptance criteria in a nutshell

Gradle will check the following for new plugins submitted to plugins.gradle.org:

  • Description and project URL are valid and not misleading
  • The group ID and artifact ID are valid and not misleading

In addition to these changes, plugins with a valid open-source repo URL will be prioritized over other plugins for approval. Those that apply a SPDX-compatible license properly, even...

❯ Read more

How to show Groovy and Kotlin DSL samples side-by-side

Gradle build script samples now have Kotlin DSL snippets alongside the Groovy snippets in Gradle 5.0 docs and many Gradle guides.

We want you to be able to show both DSLs in your READMEs and web-based documentation, so this post shows ways you can display examples in multiple languages on GitHub and on your websites.

Groovy and Kotlin DSL samples on GitHub

It’s hard to find OSS projects that don’t have a README.md or README.adoc. Though there aren’t many ways to make these README pages interactive, we can use the <details> and <summary> HTML...

❯ Read more

Introducing Exemplar for Automated Samples Testing

This post introduces a new library called Exemplar. The goal of Exemplar is to ensure that users get outputs that you expect them to see. It handles sample discovery, normalization (semantically equivalent results, perhaps from different environments), and flexible output verification. It invokes any command-line tool in the environment to be invoked. You can also invoke curl, for example, to verify service API responses.

Gradle uses this library to verify examples in docs and guides, and remove boilerplate from integration tests.

Exemplar can be configured using a JUnit test runner (recommended) or using its APIs. See examples below and in the Exemplar GitHub repo.

Exemplar Information Flow

Use cases for Exemplar

It’s important that...

❯ Read more

Stop rerunning your tests

Tests are usually the longest running operation in your development process. Running them unnecessarily is the ultimate time waster. Gradle helps you avoid this cost with its build cache and incremental build features. It knows when any of your test inputs, like your code, your dependencies or system properties, have changed. If everything stays the same, Gradle will skip the test run, saving you a lot of time.

So you can imagine my desperation when I see snippets like this on StackOverflow:

tasks.withType(Test) { outputs.upToDateWhen { false } } 

Let’s talk about what this means and why it is a bad...

❯ Read more

Fixing Gradle dependency resolution when TLS v1.1 and v1.0 support is discontinued

Maven Central and Bintray have announced that they will discontinue support for TLS v1.1 and below. Here’s what you need to know to correct your Gradle builds if you’re affected.

You will need to take action if you are using Java 6 or 7 and using Gradle versions 2.1 through 4.8.

How to check if you’re affected

You may already be getting one of the following errors from your build after an error message saying: “Could not resolve [coordinates]”:

Received fatal alert: protocol_version


peer not authenticated

❯ Read more

Using Gradle build cache with Kotlin

A build cache allows Gradle to reuse task output from any previous invocation, including those from other machines. Kotlin 1.2.21 allows Kotlin projects to make use of build caching.

The build cache works by storing compiled classes, test outputs, and other build artifacts in a cache, taking into account all task inputs, including input file contents, relevant classpaths, and task configuration.

Build Cache topological diagram

This frequently results in faster builds. The following chart shows aggregated build time with and without the build cache for part of Gradle’s CI:

Build minutes saved with Gradle build cache

In this post, we’ll explain how you can use Gradle’s build cache to avoid unnecessary Kotlin compilation to...

❯ Read more

Multi-release JARs - Good or bad idea?

With Java 9 came a new feature of the Java runtime called multi-release jars. For us at Gradle, it’s probably one of the most controversial additions to the platform. TL/DR, we think it’s a wrong answer to a real problem. This post will explain why we think so, but also explain how you can build such jars if you really want to.

Multi-release JARs, aka MRJARs, are a new feature of the Java platform, included in the Java 9 JDK. In this post, we will elaborate on the significant risks of adopting this technology and provide how one can produce and consume multi-release JARs with Gradle, if desired.

In a nutshell, multi-release jars allow you to package several versions of the same class, for consumption by different runtimes. For example, if you run on JDK 8, the Java runtime would use the Java 8 version of the class, but if you run on Java 9, it would use the Java 9 specific implementation. Similarly, if a version is built for the upcoming Java 10 release, then the runtime would use it instead of the Java 9 and default (Java 8) versions.

❯ Read more

State of Gradle Java 9 Support

This post provides an overview of Gradle’s Java 9 support, touching on runtime, cross-compilation, MRJARs, and Jigsaw modules support. We’ve fielded lots of questions since Java 9 was released last month, and decided it best to answer here.

What Gradle supports as of version 4.2.1

As of Gradle 4.2.1, building and running Java applications using major distributions of JDK 9 such as Oracle JDK9, OpenJDK9 and Azul JDK9 is fully supported. Further, cross-compilation (built by JDK9 but runs on JDK8) is supported.

Some builds will break when upgrading to Java 9, regardless of build tool used. The Java team have made good and necessary changes to the JDK to facilitate better software architecture and security, but this has meant removing access to some APIs. Even if your project is ready, some tools and Gradle plugins have not yet been updated to work with Java 9.

There is no convenience methods for consuming and assembling Multi-Release JARs, but you can take a look at this MRJAR-gradle example if you desire to use them.

❯ Read more

The Road to Gradle Script Kotlin 1.0

Five months ago we announced the first pre-release of Gradle Script Kotlin, and we thought now would be a good time to review the progress we’ve made since. We have shipped eight additional pre-releases during that time, and the road to 1.0 is looking clearer every day. So let’s take a look at the ground we’ve covered so far and where we’re going from here, shall we?


As you may recall, this is what our hello-world sample looked like at the time of our first release:

import org.gradle.api.plugins.*
import org.gradle.script.lang.kotlin.*


configure<ApplicationPluginConvention> {
    mainClassName = "samples.HelloWorld"

repositories {

dependencies {

❯ Read more

Now Open: GitHub Issues for Gradle

Gradle has been an open-source project since its inception, but as a team we haven’t always lived up to the spirit of modern open-source collaboration. For example, we haven’t made it easy for folks to stay abreast of what we’re working on, and we haven’t had a clear and simple process for users to submit feature requests or bugs against a proper issue tracker.

We’re very happy to announce that all of that is changing today. We’ve opened up GitHub Issues on the Gradle repository, and what follows are the immediate, medium-, and long-term changes we’re making to put—and keep!—the needs of the Gradle community front and center.

❯ Read more

Hello, Again

Welcome to the new Gradle blog. On behalf of the whole team, it’s my pleasure to write this first post and share a bit about what we’re up to.

Mainly, we’re putting together this new blog because we want to make sure users find out about the most important developments in Gradle-land. Our team has grown rapidly over the last couple years, and as a result we’ve shipped many new features and improvements. All too often, though, we find that would-be users never hear about them. This recent tweet provides a perfect example:

Cristian’s question is a fair one. We first shipped Play support over a year ago; we mentioned it in our Gradle 2.6 forum announcement and release notes, and we wrote a chapter about it in our user manual. Still, Cristian—and probably many others—missed it. How is that?

❯ Read more

Gradle 3.0 M1: Unleash the Daemon!

The first milestone release toward Gradle 3.0 has just been published, and among many smaller improvements, it contains two major features we’d like to get your feedback on.

The first feature is support for writing Gradle build scripts in Kotlin, and you can read all about it in last month’s Kotlin meets Gradle blog post. While still in the early stages of development, this functionality is now available out of the box with Gradle 3.0 M1, and we’d love to hear what you think. See the Gradle Script Kotlin 0.1.0 release notes for complete details and getting started instructions.

The second feature is that the Gradle Daemon is now enabled by default. This is a big deal, and I...

❯ Read more