November 2016

Table of Contents

Introduction

Welcome to the November issue of the Gradle newsletter! The end of the year may be fast approaching, but The Gradle Build Tool Team have been as busy as ever. That means we have plenty to tell you about.

First, Gradle 3.2 was released just over a week ago. Although it was a modest release in terms of features, there were still some important changes. These include:

  • Better incremental build support
  • Support for building a native (e.g. C/C++) component and its dependents with one task
  • Deprecation of the << syntax for defining tasks
  • Faster importing of projects into IDEs

You can read the details in the 3.2 release notes if you haven’t done so yet. Also note that a 3.2.1 patch release just shipped yesterday with important bug fixes related to the Gradle wrapper.

Gradle 3.2 also comes with improved support for Kotlin build scripts in the form of multi-project builds. Since then, the Gradle Script Kotlin project has seen two more releases—0.4.0 and 0.4.1—and it continues to march inexorably towards that much anticipated 1.0. You can learn about the project’s journey from version 0.1.0 and our plans for 1.0 in project lead Rodrigo B. de Oliveira’s recent blog post.

With such good progress on the project, we feel that it’s time to solve one of its weaknesses: the name! “Gradle Script Kotlin” doesn’t quite roll off the tongue, and a certain large pharmaceutical company has already claimed the abbreviation “GSK”. In any case, choosing an effective name is quite the challenge, so we need your help! We are collecting suggestions for the new identity in a special GitHub issue. To take part, simply add a comment for each name you come up with or add a thumbs up reaction to any of the existing ideas.

Another feature that has seen good progress is build scans. We’re excited to announce that there is now a brand new user manual for the Gradle Build Scan Service. If you’ve been holding off from trying build scans due to the lack of documentation, now is a perfect opportunity to dive in. And for those of you already using them, the manual will make it easier to learn about new build scan features and their configuration.

In related news, we filmed the Bay Area Gradle Users meetup earlier this month, which included talks on Composite Builds and Customizing Build Scan Data. You can find the videos in the recent blog post recapping the meetup. We recommend you check out the video on composite builds, if only to see a demonstration of their potential when used with an IDE! And the second talk is useful even for those who aren’t yet familiar with build scans.

We want to finish off here by inviting you and your colleagues to another free Introduction to Gradle training on January 11th and 12th. The first one we delivered in October was such a success that we decided to do it again. Everyone is welcome to join, including those that signed up to or even attended the October event.

Until next time!

The Gradle Build Tool Team

PS: We’d love to hear from you about any Gradle news that you consider relevant and that might be a useful addition to future newsletters. Just send us an email with the details at newsletter@gradle.com.

New Releases

  • Gradle 3.2 improves incremental build support, adds native support for building components and their dependents, includes multi-project support for builds that use Kotlin build scripts, and deprecates the << syntax for tasks.
  • Gradle Script Kotlin 0.4.1 incorporates the newly-released Kotlin 1.1-M02.
  • Build scan plugin 1.3 allows you to attach custom data via system properties. It is also more efficient when publishing build scans with large dependency graphs.
  • Gradle Enterprise 2016.4 is now available. In addition to supporting version 1.3 of the build scan plugin, this release allows you to bookmark searches within build scans via permalinks. You can also now search for tasks and filter them by task outcome. If you’re interested in a free trial of Gradle Enterprise, please contact us.

The folks at Netflix have been using Gradle extensively for quite some time and have been prolific in their creation of high quality Gradle plugins. Most significantly, they have made many of those plugins available to the community as part of their Nebula plugin collection.

In this and future newsletters, we aim to highlight some of the Nebula plugins that we think are particularly important or otherwise catch our interest:

  • The Nebula Gradle Lint plugin is a great addition to any Gradle build. Writing a maintainable build can be challenging, particularly when you’re starting out. This plugin helps you by identifying and reporting common mistakes and the use of deprecated parts of the Gradle API.
  • More advanced users will appreciate the power of Gradle’s dependency resolution engine, but may wonder how to apply their rules across multiple builds. The Nebula Gradle Resolution Rules plugin offers a solution by allowing you to package rules and import them into a build. It even comes with some rules built in!

In other parts of the ecosystem:

  • We recently encountered the interestingly-named Bullshifier by OverOps—formerly known as Takipi—which uses Gradle to generate large, random Java projects. It’s interesting to us because we have infrastructure that does something similar so that we can test the performance and scalability of Gradle itself. We can certainly see the potential for Bullshifier to help with testing Gradle plugins. If you have any other ideas and suggestions for it, do let us know either via Twitter—mention @gradle—or at the email address just below.

We’d like to help users stay aware of what’s happening throughout the Gradle ecosystem. To that end, if you know of an important new plugin or Gradle-related tool, or the release of a significant new version thereof, please let us know at newsletter@gradle.com.

Upcoming Events

Upcoming Trainings

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