Hi all! On behalf of the Gradle community, we wish you a Happy New Lunar Year! 2023 was a great year for Gradle Build Tool, with many new features and initiatives being released. Let’s recap the key updates:
Gradle 8 baseline with 7 feature packed releases
Kotlin DSL became the new default for Gradle
Configuration Caching, Build Speed and Scalability Improvements
Our First Google Summer of Code and Major League Hacking participation
Gradle Enterprise renaming to Develocity, and Gradle Build Scan enhancements
What’s next, Declarative Gradle and the road towards Gradle 9
Gradle 8
In February 2023, the Gradle team announced Gradle 8.0 - a...
One of many performance optimizations that make Gradle Build Tool fast and scalable is compilation avoidance. Gradle avoids recompiling as much as possible by determining if the result of compilation would be identical, even if upstream dependencies have changed.
The situation can be illustrated like this: if classes MyApp and NumberUtils are in different projects and MyApp’s project depends on NumberUtils’s project at compile time, then any internal change to NumberUtils does not require MyApp’s project to be recompiled. Both before and after the change, MyApp compiles to identical bytecode, so Gradle can continue to use the MyApp.class file it has already built.
On June 23rd, 2023, at 9:00 UTC, Gradle users started experiencing issues resolving artifacts from the Gradle Plugin Portal because of changes to artifacts hosted on JCenter by JFrog. JCenter stopped serving files directly and redirected all requests to Maven Central. This was an unannounced change.
We contacted JFrog, and they replied it was a test and they would revert back to having JCenter serve artifacts.
Around 18:30 UTC, JCenter returned to normal behavior.
This post describes the effect this outage had on builds, ways to recover from similar outages, and what we will do to eliminate the dependency on JCenter in the future.
Users still directly using JCenter should also refer to our original blog post about the shutdown...
Kotlin DSL for Gradle was introduced in version 3.0 of the Gradle Build Tool in August 2016 and released as 1.0 in Gradle 5.0. Since then, it’s been growing in popularity and has greatly improved the authoring experience of many Gradle builds.
Kotlin DSL is now the default choice for new Gradle builds. This means that when creating a new project with Gradle, including in IntelliJ IDEA (starting with 2023.1) and Android Studio (starting with Giraffe), Kotlin DSL is the default option. Support for Groovy DSL will continue for existing projects or those who prefer to use it.
In this post, we will explore the benefits of Kotlin DSL and why it is becoming the recommended option for new Gradle...
This is the third blog of the series How Gradle Works. In this blog we’ll explain what happens during build script execution.
Kotlin & Groovy DSL
If you are a Java developer, when you open any Gradle build script (for example build.gradle.kts or build.gradle), the first thing that might confuse you is the special syntax of curly braces:
// Kotlin DSL: plugins { id("some.plugin") version "0.0.1" } // or Groovy DSL: plugins { id "some.plugin" version "0.0.1" }
What’s this? What happens when Gradle executes these kinds of scripts?
This is the first blog of a series How Gradle Works, which includes the following topics:
How Gradle starts up
How many JVMs are involved in a Gradle build
What happens in each JVM during the build
We’ll explain the first topic How Gradle Starts Up in this blog. Before reading on, we assume you are familiar with basic JVM/Gradle concepts (jar, classpath, wrapper, daemon, project, task, etc.).
How Gradle Starts Up
There are many ways to start a Gradle build:
Local Gradle Distribution in CLI: /path/to/local/distribution/bin/gradle <SomeTask>
Gradle Wrapper in CLI: ./gradlew <SomeTask>
Click a button in your IDE to import a Gradle project or run some tests/tasks
Gradle Build Tool is an open source project, but a lot of the design work has not been as visible as it could be. Internally, we use design specifications to collaborate on new Gradle features. To make our development process more open and transparent, our design specifications are publicly available via a Google Drive folder.
This is still a work-in-progress and new documents will be added over time. We welcome community members to take a look. You can comment and provide feedback on all documents still In-Progress. We plan to use these documents to help guide new community contributions. Feel free to link to these documents in GitHub or share them with others.
We’ve recently noticed some community chatter about speeding up Gradle compilation on the JVM by ignoring changes not affecting the ABIs of dependencies. What a great idea! In fact, Gradle has used ABIs for Java out of the box for this without any extra configuration since version 3.4. We refer to this feature as compilation avoidance. This post explains what ABI-based compilation means for the average workflow. Spoiler: utilizing compilation avoidance is one of the best performance enhancements for any build.
What is an application binary interface?
An application binary interface (ABI) is the interface generated from compiling software that defines internal and external interaction. The ABI represents what is visible to consumers at compile time. When compiling a...
Test flakiness is one of the main challenges of automated testing. Even though Gradle’s focus is increasing developer productivity, the development of Gradle itself suffers from flaky automated tests. This blog explains some best practices when developing Gradle, which have proved effective over the years we fight with flaky tests.
The Story
Like in many other projects, every commit of Gradle must pass tens of thousands of automated tests. Any tiny flakiness may cause developer productivity loss. When I joined Gradle 5 years ago, the CI was full of flaky test failures - people would rerun a build, again and again, hoping to be lucky enough to get a green build.
Later, we started a dedicated developer productivity team to deal...
GitHub Actions provides a convenient and powerful CI platform for projects hosted on GitHub. To enhance the experience of building Gradle projects on GitHub Actions, the Gradle team has developed the gradle-build-action. Together with Gradle Build Scans™, the gradle-build-action provides deep integration between Gradle and GitHub Actions, providing easier setup and a better experience when building and testing your Gradle project with GitHub Actions.
The gradle-build-action is the officially supported way to run your Gradle build in GitHub Actions, taking care of preparing and optimizing Gradle for your GitHub Actions workflow. When applied to a workflow, all subsequent Gradle invocations will be optimized, allowing you to simply run...
Configuring the publication of Gradle plugins to the Portal happens with the help of the Plugin-Publish plugin. The recently released version 1.0.0 of the plugin significantly improves the process by having stronger opinions and a more straightforward configuration.
Stronger Conventions
Gradle plugin development has a long history and has gradually evolved to use helper plugins to aid you with setting up your plugin project. The most important ones:
The Plugin-Publish plugin shares this long history, and it ended up supporting all the various combinations of helper plugins. This results in too many ways of publishing plugins, and too many configuration options,...
The Remote and Distributed Build Patterns article explains the differences between remote and distributed builds and variations on each. Specifically, we distinguished between “test distribution” and “general build distribution”.
This article discusses distributed builds in a broader perspective of improving build feedback times. We’ll start by explaining the types of changes engineers tend to make, identify the typical bottlenecks and share how these relate to distributed builds. We will also study the performance potential of general build distribution. Finally, we will explore a holistic approach to improving build feedback times.
In greater detail below, we will elaborate on these three findings:
Building in a distributed fashion is not a substitute for a well-tuned build process.
A frequently-requested feature for the Gradle Build Tool is the ability to perform remote or distributed builds. But what exactly does this mean? And what are the motivations behind the requests? This post will explore the difference between remote vs. distributed builds and their variations. As there is no industry-wide agreement on consistent terminology for these concepts, the goal of this post is to give an overview of these patterns and how they relate to each other.
Except for two JVM-specific references, these observations are generally applicable to software projects using any language or ecosystem.
But Why?
These features are typically discussed in the context of shortening build times on local developer machines. Extended build turnaround times hinder productivity in both...
The lack of diversity in the technical world is a chronic, pervasive issue. For example, a 2021 global software developer survey showed that female software developers are only 5 percent of the population. This is something we need to change.
To help promote diversity in our industry, Gradle is excited to announce a new mentorship program. The program is open to everyone, but we’ll be prioritizing mentees from underrepresented segments of the developer community, including women, and Black and Hispanic individuals, who want support and enhanced professional development from members of the Gradle Build Tool community. Mentees in the program will have access to personalized discussions on using Gradle Build Tool, build automation, developer productivity and more.
We are excited to announce that the Gradle Build Tool roadmap is now public. See the roadmap board and the associated readme.
Motivation
The Gradle Build Tool project regularly ships new releases full of new features and bug fixes. So far our main channels of communication with the user community to share plans and get feedback were release notes, blog, issue tracker, forums, and community Slack. However, we lacked a high-level overview of what’s planned in the upcoming releases.
About the roadmap
Today, we are announcing our new roadmap board hosted on GitHub. It lists major projects and user-facing features, organized by quarter and target release.
On January 12th 2022, Gradle users were experiencing issues resolving plugins from the Gradle Plugin Portal because of the outage of JCenter that the Plugin Portal depends on for some of the functionality.
This postmortem gives a timeline of the outage, describes the effect on Gradle users, and what actions were taken to further reduce the Gradle Plugin Portal’s reliance on JCenter.
Finally, we will also discuss how you can protect your build against such outages.
Users affected by JCenter outages for project dependencies should also refer to our original blog post about the shutdown of JCenter.
Outage timeline
4.30pm UTC, January 12th Outage begins
Gradle users start noticing that plugin resolution is failing in builds.
New Gradle plugins undergo a manual inspection before they get approved to be published in the Plugin Portal. Most of the performed checks are now fully automated in order to reduce wait time for plugin authors and reduce the risk of human errors. This blog post describes the new automation affecting community plugin authors and explains that it is important for the security of the ecosystem.
Plugin Publishing Security
One of our priorities at Gradle is reducing the risk of supply chain attacks. Such insidious attacks can have a very large scale and impact. For example, a malicious community plugin may potentially infect a large number of software systems built with Gradle. You can read more about such attacks and...
Community is instrumental to the success of every open-source project. At Gradle, we are very fortunate to serve and collaborate with an amazing community of users, champions, and plugin authors.
Some of the community members go above and beyond to help other users succeed. We are extremely grateful for their dedication. Their valuable contributions to the community include helping others on the Gradle Forums and Community Slack, publishing blog posts and presenting at conferences and user groups.
We are excited to introduce the Gradle Fellowship program to recognize and connect those individuals and grow this global community of Gradle experts to help the broader Gradle community be more productive.
We’ll support the Gradle Fellows in their efforts by offering additional...
One of the biggest success factors of Gradle is its community. There is no day that goes by without users suggesting new features, finding and reproducing defects or opening a pull request with a contribution. We appreciate every single issue that users create. Thank you!
Working on a successful project like Gradle comes with challenges, be it the number of questions and contributions or deciding which aspect has the highest priority for the team. Even though we don’t like to accept it, we don’t have infinite capacity. We want our teams to be able to focus on producing the most value for our users. That means fixing the right bugs and implementing the best features. Given the diversity of our community, this...
Gradle 6.0 is the culmination of several years of innovative improvements in Dependency Management. Embracing the idea that there is more to software composition and reuse than just putting a set of jar files on the classpath, Gradle now offers a new metadata format to richly define software components that are often made up of multiple files, different variants and specific constraints on their dependencies.
In particular, in this webcast Developer Advocate Jenn Strater and Gradle Engineer Jendrik Johannes discuss:
Recently I was helping an Android team investigate a hard-to-reproduce issue that manifested as very-long-running compilation and annotation processing tasks. Most of their builds took only a few minutes to run, but sometimes they took up to 30 minutes! In these cases, invariably, a build scan showed that some combination of Java compilation, Kotlin compilation, or annotation processing with Kapt, was the culprit. The team had no real idea of how often this problem occurred for developers, and under what conditions.
Gradle Enterprise does not, yet, provide a way to find builds based on how long a particular task took. However, custom tags make it easy to categorize and find builds for any condition that can be detected within a build. By...
A lot has changed for Gradle since version 4.0 was released in mid-2017.
Gradle 5.0 is much faster and more memory efficient than previous versions of Gradle, has better tools to inspect and manage transitive dependencies, and can provide the IDE assistance you’d always hoped and expected through a new Kotlin DSL.
This 1-hour webcast demonstrates 4 key themes of Gradle 5.0:
What Gradle’s Kotlin DSL does and who should adopt it How to take full advantage of incremental compilation and annotation processing Why unexpected dependency version X was selected and how to fix it What new task APIs are available in Gradle 5.0 If you prefer just the info, check out this page on the highlights of Gradle 5.0 and...
Gradle is updating the plugin approval policy for plugins submitted to the Gradle Plugin Portal, effective today, to begin adding stronger security safeguards for plugin consumers.
First off, this does not affect plugins already on the plugin portal, just new plugins. Gradle builds that use plugins will not be affected in any way.
Portal acceptance criteria in a nutshell
Gradle will check the following for new plugins submitted to plugins.gradle.org:
Description and project URL are valid and not misleading
The group ID and artifact ID are valid and not misleading
In addition to these changes, plugins with a valid open-source repo URL will be prioritized over other plugins for approval. Those that apply a SPDX-compatible license properly, even...
Gradle build script samples now have Kotlin DSL snippets alongside the Groovy snippets in Gradle 5.0 docs and many Gradle guides.
We want you to be able to show both DSLs in your READMEs and web-based documentation, so this post shows ways you can display examples in multiple languages on GitHub and on your websites.
Groovy and Kotlin DSL samples on GitHub
It’s hard to find OSS projects that don’t have a README.md or README.adoc. Though there aren’t many ways to make these README pages interactive, we can use the <details> and <summary> HTML...
This post introduces a new library called Exemplar. The goal of Exemplar is to ensure that users get outputs that you expect them to see. It handles sample discovery, normalization (semantically equivalent results, perhaps from different environments), and flexible output verification. It invokes any command-line tool in the environment to be invoked. You can also invoke curl, for example, to verify service API responses.
Gradle uses this library to verify examples in docs and guides, and remove boilerplate from integration tests.
Exemplar can be configured using a JUnit test runner (recommended) or using its APIs. See examples below and in the Exemplar GitHub repo.
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 a bad...
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]”:
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.
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:
In this post, we’ll explain how you can use Gradle’s build cache to avoid unnecessary Kotlin compilation to...
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.
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.
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:
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.
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:
I read news, I try to keep up-to-date. So how did I miss that @gradle can build @playframework? Gotta look into this.
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?
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 Kotlin0.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
