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 always wrong.

...

❯ 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

or

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?

v0.1.0

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.*

apply<ApplicationPlugin>()

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

repositories {
    jcenter()
}

dependencies {
    "testCompile"("junit:junit:4.12")
}

❯ 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