March 2017

Table of Contents

Major News

Welcome to the March 2017 Gradle newsletter! We are working hard on the upcoming Gradle 3.5 release. Toward that end, we announced the new release candidate, RC3, which provides a new build cache as well as an improved console for parallel builds. There is now a Gradle Profiler available as well, to automate performance measurements and profiling of Gradle builds.

Two major presentations are notable this month. First, Stefan Oehme recorded a webinar with Trisha Gee from JetBrains on how to take advantage of composite builds with IntelliJ IDEA. Second, Hans Dockter gave a well-received talk with Xavier Ducrohet(video), Lead of Android Developer Tools, on the major performance improvements for building Android applications and libraries with Gradle and the Gradle Android plugin. The talk was given to a large, enthusiastic audience at the San Francisco Android User Group.

We also invite the community to help us improving Gradle configuration time, by providing us data from real-world Java builds with configuration times above 1s. See instructions on Github https://github.com/gradle/gradle/issues/1628 for details on how to participate. The configuration time for Android projects is dramatically improved in Android Plugin 2.5. Until that version is stable, we don’t think that profiling Android builds is worth your time.

Links for everything are here:

  • Gradle 3.5 RC 3 is now available, featuring a new build cache and new console output! The full 3.5 release expected very soon and will be covered in the April newsletter.

  • Gradle Profiler lets you automate performance measurements of Gradle builds either with Gradle build scans or YourKit, JProfiler, Honest Profiler, among other tools.

  • Buildship 2.0.1 is now available through the Eclipse Marketplace. The latest release contains several bug fixes for issues identified by the community. You can now follow the project on GitHub at with the ZenHub extension in your browser.

  • Gradle images on Docker. Gradle images now available in the official Docker repository, featuring Gradle 3.4.1 on Java 7 and 8.

  • gradle-script-kotlin version 0.8 is a major update and will be included in Gradle 3.5. The plugin now uses Kotlin 1.1 with the new co-routines support.

  • Hans Dockter on Extremely Fast Android Builds with Gradle(video): Hans and Xavier Ducrohet spoke at the San Francisco Android User Group on March 28 that discussed the major performance improvements coming in version 2.5 of the Android plugin for Gradle.

Hans Dockter on Extremely Fast Android Builds with Gradle

  • IntelliJ Webinar on Gradle Composite Builds by Stefan Oehme and Trisha Gee demonstrates how to use the composite build capabilities. Stefan covered the basic use cases and shows how easy it is to use, and Trisha demonstrated the excellent IDE support.

  • Gradle configuration time initiative: get configuration time insights from real world builds. We invite the community to help us find the biggest performance problems during configuration time on “Java Enterprise” projects. See the link for details about how to run a build that can supply the team with performance information.

  • The Pony Gradle Plugin lets you compile Pony sources and resolve dependencies. Pony is a language for provably safe, lockless concurrency. It is an open-source, secure language that uses an actor model for high-performance concurrency.

  • The dependency lock plugin from Netflix can generate a lock file that contains explicit versions for each of your Gradle dependencies. This makes it easy to produce predictable and reproducible builds.

Upcoming Event

  • Jun 22-23: Gradle Summit. This is the featured event of the year. The focus is on increasing developer productivity with Gradle. Registration is open now. The call for papers (summit.gradle.com/speak) ends April 7th, so if you are interested in presenting, please add your proposal as soon as possible.

Upcoming Trainings

The New Build Cache

The Gradle build cache is a cache mechanism that aims to save time by reusing outputs produced by other builds. The build cache works by storing (locally or remotely) build outputs and allowing builds to fetch these outputs from the cache when it is determined that inputs have not changed, avoiding the expensive work of regenerating them.

A first feature using the build cache is task output caching. Essentially, task output caching leverages the same intelligence as up-to-date checks that Gradle uses to avoid work when a previous local build has already produced a set of task outputs. But instead of being limited to the previous build in the same workspace, task output caching allows Gradle to reuse task outputs from any earlier build in any location on the local machine. When using a shared build cache for task output caching this even works across developer machines and build agents.

If you have some news you’d like us to share in the next issue, let us know using the #community-news channel on the Gradle Community Slack or by mentioning @Gradle on Twitter/X.

Until next time!
— The Gradle Team