Gradle Summit 2016
Gradle is the most popular build tool in the world — or so said Hans Dokter, CEO and Founder of Gradle Inc., in his keynote address at the 2016 Gradle Summit in Palo Alto, CA, last month. I was fortunate enough to be able to attend this year, and learned a lot from some of the world’s most accomplished build masters. Let’s jump right in and see what’s happening in the world of Gradle right now.
Highlights From The Gradle Keynote
Buildship 2.0
Buildship 2.0 is due to be released in November of this year. More than just an Eclipse plugin, it’s also Gradle’s reference implementation for IDE support, so it has relevance to anyone using a Gradle-supported IDE (such as Android Studio).
Improvements to Gradle itself
Subtitle: Speed is King
- Gradle 3.0 M2 (milestone 2) was released a day before the summit began. The main new feature to look forward to is that the daemon will now be enabled by default. It is also 35% faster! As it “warms up” (is used), it gets faster and faster, as it makes intelligent optimizations to its process.
- Kotlin support continues to grow, with M2 released alongside Gradle 3.0 M2. A build file written in Kotlin would have a filename like `build.gradle.kts`. While I don’t consider Kotlin scripting support to be fully production-ready, yet, I am eager to see it reach that point. I really want static analysis in my build script. See the link for more information on how to experiment with Kotlin in your build script.
- Composite builds are amazing. They allow developers to treat several distinct Gradle projects as one single composite project. To have one project depend on another, you would edit your settings.gradle file to add the line `includeBuild(“project-name”)`. This shortcuts the need to depend on the dependency’s published artifact — you can depend on the project itself, and not worry about tracking bug fixes manually. See here for more details.
- While we may have Gradle 3.0 on the horizon, for those of us who prefer to keep off the bleeding edge, there is Gradle 2.14, which is fully production-ready, and 36% faster than the prior version. Configuration time alone is 2-5 times faster, and static analysis is over 2 times faster.
- Gradle is introducing a distributed cache. Who says all caches must be local? Why should every member of your team have to build locally and maintain a local cache, when they could instead take advantage of the cache built by another team member earlier in the day?
Gradle Cloud Services
The highlight of the keynote was the unveiling of Gradle Cloud Services. Gradle is clearly updating their business model here, with a new emphasis on enterprise support. Nonetheless, there remains a free cloud offering for those who don’t wish to dive into a monthly support contract. That free service is the Gradle Build Scan, which provides detailed information on builds that run with it enabled. If you’re not enabling build scans by now, you’re already falling behind. See here for information on how to use this new tool.
Hans Dokter closed his keynote by talking about his desire to see “the build” become more professionalized, i.e., with the build getting the same attention to detail as our production code gets. We can and should test our build code. We should integrate it more deeply with our CI systems and move to CD (continuous deployment). Build engineers and build masters have the opportunity to keep pushing the DevOps revolution — and Gradle will enable it.
Session highlights
How to Measure Your Gradle DX, with Janelle Klein
One of the more interesting sessions was given by Janelle Klein, a senior developer, author, and speaker, titled “How to Measure Your Gradle DX.” DX, or “Developer Experience,” is the twin to UX, or “User Experience.” A subtitle to this talk may have been “How to Measure Your Development Pain.” My favorite slide from the presentation included these four images:
I think we can all relate to these images. They reflect the increasing pain we all feel as the codebase grows and we increasingly find ourselves wading through unfamiliar waters. In fact, this is the major finding from Janelle’s work: most mistakes are made in parts of the code with which we are unfamiliar, and pain occurs during the process of understanding software. The classic story of project failure is your manager wants the new feature now, and you spend upwards of 90% of your time on friction (understanding unfamiliar code), before finally hacking together a solution.
An effort is currently underway, called OpenMastery (or data-driven software mastery), to gather developers from the community to help better understand and utilize this concept for making the learning process more transparent. Taking inspiration from The Goal, Janelle suggests that developers should learn to communicate in terms of risk rather than cost — and this will be one of the fundamental features of the OpenMastery project. Learn more at the website, and on the OpenMastery Slack channel, openmastery.slack.com.
Gradle Lint
The winner of this year’s Gradle Awards for Best Plugin, Gradle Lint is part of Netflix’s Nebula OSS suite. Applying it allows Gradle users to ensure their build scripts are kept up to date and employ best practices. The plugin comes with a number of pre-defined rules, which may be enabled individually; as well as the ability to write custom rules. What makes the plugin so powerful is that not only will it identify issues, but also provide fixes automatically. One of my favorite default rules will discover transitive dependencies that are referenced directly in your source code, and promote them to first-class dependencies.
Better Android Development With Kotlin and Gradle
Android development is caught in a Java purgatory. While we do have access to most Java 7 features (but not try-with-resources!), and even (some parts of) Java 8 if we use Retrolambda or are building against Android N with the new Jack compiler, it’s probably safe to assume we’ll never have Java 9 or beyond — not in our lifetimes, anyway. Enter Kotlin: a JVM language with complete interoperability with Java code, null-safety, reduced boilerplate, extension methods, the end of checked exceptions, and much, much more. Kotlin is making impressive progress, and within the year I expect much better Gradle and Android Studio / IDE support.
There’s Always More
The Gradle Summit was a blast. It would be impossible to convey all of the fun I had and knowledge I gathered in this article. Hopefully the article and these last two tidbits will leave you with an interest in Gradle and a smile.
- During a panel session, a representative from IntelliJ was asked how they build their products. Amusingly, the answer was “Ant….”
- If you’re a native C/C++ developer, consider using Gradle. Why? Because it was actually developed as an open source project by the Government of Canada, so it would be a very friendly and sensible thing to do.
