March 2017

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:

Hans Dockter on Extremely Fast Android Builds with Gradle

Upcoming Event

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

Gradle Inc. | 2261 Market Street | San Francisco, CA 94114
Privacy Policy | Unsubscribe