Announcing Buildship 2.0

We are pleased to announce that version 2.0 of Buildship—our official Gradle support for Eclipse—is now available via the Eclipse Marketplace. This release adds support for composite builds, greatly reducing development turnaround time. The UI has been redesigned based on plenty of community feedback during the 1.x line. Project synchronization is now more accurate and project import requires one less step. We’ve added support for Gradle’s offline mode (thanks Rodrigue!), and last but not least, third-party integrators can take advantage of our new InvocationCustomizer extension point. Read on for details about each of these new features.

Composite build support

What is a composite build?

The composite build feature in Gradle allows you to handle several distinct Gradle builds as if they were one big multi-project build. This dramatically shortens the turnaround time when you need to work on several projects that are normally developed separately.

Let’s assume you have written a Java library lib, used by many of your applications. You find a bug which only manifests itself in the special-app. The traditional development workflow would be to change some code in lib and install a snapshot into the local repository. Then you would have to change the build script of special-app to use that new snapshot and check if the bug is actually fixed.

With composite builds, however, you can tell Gradle to treat both of these projects as one. This will let special-app depend directly on the output of the lib project.

You can learn more about composite builds in this introductory blog post.

Composite builds in the IDE

If you develop special-app you probably have it imported in Eclipse with lib referenced as a binary dependency.

Buildship workspace

There is not much difference between working with composite builds at the command line and working with them within Eclipse. To include lib you need only add an entry to your settings.gradle file, telling Gradle from which folder the additional build should be included.

includeBuild '../lib'

Then, to apply the changes right-click on the project and select Gradle > Refresh Project. After the synchronization finishes, you should see two things: the project from the included build is imported and the binary dependency is replaced with a project dependency.

Imported composite

Now, you can make changes to both projects with the benefit of complete IDE support: error markers, code completion, refactoring and more. Also, if you execute Gradle tests—or any other build task—from the Gradle Tasks view, the execution considers changes from the included builds.

Task execution with included builds

Limitations

When using composite builds from the IDE you should be aware of the following limitations:

  • Composite builds support only works if the imported project uses Gradle 3.3 or above.
  • Task execution is disabled on included builds due to a task addressing limitation in Gradle.
  • Including WTP projects into a composite is not supported.

Design overhaul

We updated the Buildship user interface to align it with current Gradle branding as well as with the Eclipse design guidelines. The icons are now distinguishable by color-blind people and work well with Eclipse’s dark theme. Finally, high-definition images have been put in place for use with High-DPI displays.

New Buildship design

Import wizard simplification

We removed JAVA_HOME, program arguments, and JVM arguments configuration from the import and new project wizards. Users can still configure these properties via the gradle.properties file.

More accurate project synchronization

In Buildship 1.x if the project being imported had Eclipse descriptors then a dialog was shown to determine if those descriptors should be updated or deleted. This behavior was error-prone and distracting for users.

To avoid showing a dialog, we improved the project synchronization algorithm the following way: If the Gradle version used by the project can provide a specific attribute (e.g. project natures), it is completely overwritten. Manual modifications are only kept if Gradle provides no information about that attribute. This allows users of older Gradle versions to work around missing information in the model, while giving users of new Gradle versions a much more consistent experience.

Offline mode support

Users can now set Buildship to work offline via the workspace preferences. Once enabled, all Gradle invocations will receive an extra --offline argument.

Offline mode support in preferences

InvocationCustomizer extension point

The InvocationCustomizer extension point enables Eclipse plugins to contribute extra arguments to Gradle builds. This allows integrators to add init scripts or control project properties from the IDE. For a sample implementation check out the Buildship documentation.

Breaking changes

This release introduces the following breaking changes:

  • Minimum Java version set to 1.7
  • Minimum Eclipse version is set to 4.2
  • Project renaming is disabled for projects that are located directly under the Eclipse workspace location.
  • Projects migrating from Eclipse Mars directly to Eclipse Oxygen need to be reimported
  • JAVA_HOME can no longer be configured on import, please use gradle.properties instead
  • Java arguments and Gradle properties can no longer be configured on import, please use gradle.properties instead

Installation

Buildship 2.0 is available from the Eclipse Marketplace or from the eclipse.org update sites. Please note that the update site URL has changed therefore no automatic update is available for this release.

Custom Data in Build Scans

Build scans are a great way to easily share data about your build, but what if your team wants to add their own data to those build scans? They can! In addition to the extensive information automatically captured in build scans, you can attach your own custom data to provide even deeper insights into your build. This custom data can take the form of tags, links, and arbitrary custom values in a key-value format.

By adding custom data to your build scans you can make it easy to find builds of a certain type, give quick links to the applicable source code commit on GitHub, add helpful CI build information, and much more. Then, when you share the single build scan link with a teammate, they get quick and easy access to a plethora of information about your build, making it easier for them to diagnose build environment issues, fix test failures, and so on.

If build scans are new to you, you can learn about them in our introductory blog post on the topic. You can also find more details in the Build Scans User Manual, explore some example build scans or experiment with this sample build scan project.

Now let’s go through some examples of adding custom data into your build scans (see the user manual for additional examples).

Tags

Let’s start with the simplest type of custom data: tags. Tags are a way to add simple pieces of metadata to your build scan. You can use tags to add context to your build, such as whether the build was run locally or on a CI server, whether the build had any local changes, the error type of a failing build, etc. Here is an example build scan that tags the build as having:

  • run on CI
  • come from the master branch
  • included local code changes (“dirty”)

For example, to attach a tag showing whether the build ran locally or on a CI server, you can add the following to its build script:

if (System.getenv("CI")) {
    buildScan.tag "CI"
} else {
    buildScan.tag "LOCAL"
}

The tag is then displayed under the project name when viewing the build scan:

Build scan tag

In addition to tags, you can include links that readers of your build scan might find useful. For example, you could include a convenient link to the project source on GitHub or a link to the CI results of the Gradle build. This example build scan demonstrates what such links look like.

Let’s say your CI tool makes the build results URL available as an environment variable. You could grab that value and add it as a custom link by using the following code in your build script:

if (System.getenv("CI")) {
    buildScan.link "CI build", System.getenv("BUILD_URL")
}

You also have the flexibility to add a link to the current revision or commit of the project’s source code. The following example links the build scan to its corresponding commit on GitHub (as long as the Git command line tools are available):

String commitId = 'git rev-parse --verify HEAD'.execute().text.trim()

buildScan.link "Source", "https://github.com/gradle/gradle-build-scan-quickstart/tree/" + commitId

Links are displayed in the top section when viewing the build scan:

Build scan links

Custom values

Custom values can be used to make any information part of the build scan. In this example build scan, you can see the corresponding CI build date, CI build number and the name of the Git branch as custom values. These values are available when viewing the build scan or when searching for build scans in Gradle Enterprise. Let’s go through a couple of examples showing how you can add custom values to your build scan.

In our first example, we assume your CI tool injects build information into the build via environment variables. You could then use the following code in your build script to attach the build number and date to the build scan:

if (System.getenv("CI")) {
    buildScan.value "CI build number", System.getenv("BUILD_NUMBER")
    buildScan.value "CI build date", System.getenv("BUILD_DATE")
}

Since we are setting these custom values from inside a Gradle build script, you have the power to do things like run external commands to capture more information about the project status. For example, you could add the current Git branch of the build by running a Git command and setting a custom value with the result:

String branchName = 'git rev-parse --abbrev-ref HEAD'.execute().text.trim()

buildScan.value "Git branch", branchName

The custom values are displayed on the main page when viewing the build scan:

Build scan custom values

Command line

To give you greater flexibility in how you pass custom data to your build scan, you can also specify tags, links, and custom values on the command line. For example, you can quickly attach ad-hoc information to your build scan in order to:

  • help debug a specific local build failure
  • tag an experimental build
  • add CI-specific custom data without modifying your build script

You do this by specifying system properties with the appropriate names, as demonstrated by these examples:

$ gradle build -Dscan.tag.EXPERIMENTAL

$ gradle build -Dscan.link.buildUrl=$CI_BUILD_URL

$ gradle build -Dscan.value.buildNumber=$CI_BUILD_NUMBER

The first adds a tag named “EXPERIMENTAL”, the second adds a link titled “buildUrl”, and the third adds a custom value called “buildNumber”.

Searching based on custom data

When using build scans on-premises with Gradle Enterprise, you can search for build scans based on custom data such as tags and custom values. For example, you can search for all builds that ran on CI against the master branch using the terms shown in this screenshot:

Build scan serch results

Live Demo

For a live demo of adding custom data with even more examples, check out this recent talk by Luke Daley and Etienne Studer at the Bay Area Gradle Users meetup. The video starts with an overview of build scans and dives into the details of adding custom data around the 22:30 mark.

Adding custom data to your build scans gives you the power and flexibility to augment your build scans with tags, links, or other data tailored to your team’s specific needs. Then you have even more information available to easily share with your teammates in a build scan—reducing the guesswork of diagnosing build failures. Happy scanning!

Save the Date: Free Gradle Training in January

Getting started with a new technology can be daunting. Learning the basics by reading manuals and blog posts and searching forums can be time-consuming. And getting a whole team up to speed is a challenge all its own. That’s why for years now, we’ve offered a range of Gradle training courses to help teams fast-track the process of learning and mastering Gradle.

Our flagship Introduction to Gradle course has always been our most popular, and in October we ran an experiment with it: we gave it away for free. That’s a steep discount from the usual price of $900 per seat, but we wanted to see just how many people we could help to learn Gradle if cost were not a factor.

We’re happy to report that this first free training was an overwhelming success, and are even happier to announce that we’ll offer a second free Introduction to Gradle training on January 11th and 12th. The course will be led by Gradle veterans Gary Hale and Ben Muschko over these two consecutive, 4-hour training days.

In it, you and your colleagues will get everything you need to start creating and running your own Gradle builds with confidence. There will be plenty of hands-on labs and opportunies for Q&A with the instructors. We look forward to seeing you there!

Details:

  • When? 8:30am–12:30am PST on January 11–12, 2017
  • Where? Online via Zoom webinar - Register Now

November 15th Bay Area Gradle Users Meetup: Recap and Videos

We’d like to thank everyone that came along to our Bay Area Gradle Users meetup last week, and we’d like to thank LinkedIn once again for hosting us—it was a great event! For those who were unable to attend for reasons of distance, time or anything else, we filmed both sessions and are delighted to make the videos available to everyone.

As described in that earlier blog post, Szczepan Faber and Hans Dockter talked in detail about Gradle’s new composite build feature:

In particular, Szczepan demonstrated the potential for working with multi-repository projects in an IDE as if they were part of the same multi-project build. You’ll find that in the first 10 minutes of the video.

That talk was followed by Luke Daley and Etienne Studer presenting the advantages of using custom data in your build scans:

It’s well worth setting aside some time to watch both of these if you can.

We hope you find these videos useful and we look forward to seeing many of you at the next meetup!

Webinar: Customizing Build Scan Data

For those of you who can’t make our Bay Area meetup on November 15th, we’re putting on a webinar a couple days later that will cover one of the same topics: customizing build scan data. Even better, the webinar will be delivered by one of Gradle’s best: Mark Vieira! So come join us for a half-hour of valuable learning and discover how to maximize the benefit of your build scans.

Details:

  • When? 11:00 - 11:30am PT on November 17, 2016
  • Where? Online via Zoom webinar - Register Now

There will be an opportunity for Q&A and a recording of the webinar will be made available to attendees. We hope you’ll join us!

November 15th Bay Area Gradle Users Meetup

Everyone has an opportunity to engage with the Gradle team online through a variety of channels, but nothing beats meeting people face to face. If you are around the Silicon Valley area on November 15th, you can meet three of the team at the Bay Area Gradle Users meetup along with an expert user and build master from LinkedIn.

We have two great talks lined up, the first of which introduces you to an exciting new feature within Gradle—composite builds—while the second shows you how to get more out of your build scans with custom data.

Details:

  • Who? Hans Dockter, Szczepan Faber (LinkedIn), Luke Daley, Etienne Studer
  • When? 6:00pm PT on November 15, 2016
  • Where? LinkedIn, 605 W. Maude, Sunnyvale, CA
  • RSVP: If you plan to attend, please register beforehand via Eventbrite

We hope to see you there!

Hans Dockter and Szczepan Faber on Composite Builds

Many of you will be familiar with Gradle’s multi-project build support which allows you set up dependencies between projects, e.g. where the output of one project—say, a JAR file—is required by another. But this only works if the projects are part of the same multi-project build.

In this talk, Hans and Szczepan will explain how Gradle’s new support for composite builds extends this behavior to projects that are otherwise independent of one another. Want to test a local fix to a library one of your projects depends on? Now you can—without having to publish a new version of that library. Composite builds also enable structuring your projects in new ways, since you no longer need to keep all projects in one repository or directory hierarchy.

Hans won’t just talk about the topic, he’ll also show you how the feature works in practice. You’ll come away with a firm understanding of the value of composite builds and how you might put them to use in your own projects.

Luke Daley and Etienne Studer on Customizing Build Scan Data

Build scans already provide deep insights into your build by reporting key metrics and data. These are incredibly useful on their own, but Gradle is designed around the understanding that no two builds are the same. That’s why build scans allow you to add custom tags, links, and values from your builds. These custom annotations can help you bring out insights that are very specific to your build and to the environment in which your build is run.

In this talk, Luke and Etienne will show examples of how you can use this feature to add extra value to your build scans. The aim is to sow the seeds of inspiration for your own builds using a feature that you might otherwise overlook.

The Road to Gradle Script Kotlin 1.0

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:

import org.gradle.api.plugins.*
import org.gradle.script.lang.kotlin.*

apply<ApplicationPlugin>()

configure<ApplicationPluginConvention> {
    mainClassName = "samples.HelloWorld"
}

repositories {
    jcenter()
}

dependencies {
    "testCompile"("junit:junit:4.12")
}

Oh, that annoying org.gradle.script.lang.kotlin.* import! The publicly condemned, IDE unfriendly, string-based "testCompile" dependency configuration! And of course—for those souls brave enough to have tried them—the infamous generateKtsConfig and patchIdeaConfig tasks required to get Kotlin-based build scripts working in IDEA. These were early days, no doubt, and they brought with them a few rough edges.

But despite its flaws, the programming language and IDE experience in 0.1.0 was already so good it got us hooked. As for the rough edges, we could already see ways to smooth them out, which led to the release of 0.2.0 one month later.

v0.2.0

With implicit imports and a tooling-friendly alternative to string-based dependency configurations, hello-world 0.2.0 started looking clean and concise:

apply<ApplicationPlugin>()

configure<ApplicationPluginConvention> {
    mainClassName = "samples.HelloWorld"
}

repositories {
    jcenter()
}

dependencies {
    testCompile("junit:junit:4.12")
}

Seamless project imports meant that Kotlin-based builds in IDEA started working out of the box, and the days of mistyping generateKtsConfig and patchIdeaConfig were no more.

Perhaps most importantly, 0.2.0’s support for build script dependencies and external plugins made Gradle Script Kotlin a viable choice for many real-world projects.

v0.3.0

0.3.0 was a major milestone for the project, as it was the first version to be included in a production Gradle distribution—Gradle 3.0, no less!

And 0.3.0 was all about that Kotlin! The new Kotlin 1.1-M01 compiler, support for Kotlin-based plugins and buildSrc directories plus some sugary Kotlin-Groovy interoperability primitives:

gradle.buildFinished(closureOf<BuildResult> {
    println("$action finished") // $action refers to BuildResult.getAction()
})

With Gradle 3.0 out the door, the #gradle channel of the public Kotlin Slack saw an increase in participation which helped us greatly in prioritizing the work that would come next.

v0.3.1

We noticed people struggling with the lack of a more type-safe and IDE-friendly way of configuring dependencies, so 0.3.1 came with a much-improved dependencies DSL:

dependencies {

    default(group = "org.gradle", name = "foo", version = "1.0") {
        isForce = true
    }

    compile(group = "org.gradle", name = "bar") {
        exclude(module = "foo")
    }

    runtime("org.gradle:baz:1.0-SNAPSHOT") {
        isChanging = true
        isTransitive = false
    }

    testCompile(group = "junit", name = "junit")

    testRuntime(project(path = ":core")) {
        exclude(group = "org.gradle")
    }
}

The upgrade to Kotlin 1.1-dev-2053 notably enhanced the performance of code assistance within IDEA and thanks to a valuable member of the community the first Gradle Script Kotlin Android sample was published.

v0.3.2

With 0.3.2 we decided to tackle the dreaded it problem head-on via runtime code generation of Kotlin extensions. What is the dreaded it problem? Take the use of copySpec as an example. Prior to 0.3.2, one would have written:

copySpec {
    it.from("src/data")
    it.include("*.properties")
}

This syntax didn’t read very well, and was a departure from the fluid, readable DSL Gradle has long been known for. But never fear—with 0.3.2 it was gone:

copySpec {
    from("src/data")
    include("*.properties")
}

v0.3.3 and v0.4.0

The recently-released versions 0.3.3 and 0.4.0 shipped the first of a series of improvements to multi-project builds including the ability to define custom build logic using Kotlin in buildSrc.

0.4.0 is available now and will ship with the forthcoming Gradle 3.2 distribution.

Toward v1.0.0

What’s next, you ask? Here are some of the highlights of our upcoming releases in three key areas:

  1. Performance: Faster project configuration via caching of compiled build scripts (#31).
  2. Usability: Type-safe accessors for extensions and conventions contributed by plugins (#159); Comprehensive documentation (#106).
  3. Convenience: Declarative and tooling-friendly application of plugins, a.k.a., the plugins block (#168).

Altogether, here’s how we envision the hello-world sample will look in Gradle Script Kotlin 1.0:

plugins {
    application
}

application {
    mainClassName = "samples.HelloWorld"
}

repositories {
    jcenter()
}

dependencies {
    testCompile("junit:junit:4.12")
}

How does that look to you? We’d love to hear what you think.

A big thanks to everyone that’s been along for the ride so far, and if you’re just getting started with Gradle Script Kotlin, welcome!

Now Open: GitHub Issues for Gradle

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.

Effective Immediately

✔︎ You can now submit feature requests and bugs through GitHub Issues. We’ve put together a simple set of guidelines in the form of an issue template so you’ll be presented with them each time you submit a new issue. We’ll label issues that don’t follow these guidelines as not-actionable and we’ll add a comment asking for what’s missing. To keep things clean, we’ll close these issues after a week of inactivity.

✔︎ Actionable issues you submit will be prioritized alongside other Gradle improvements. Low-cost changes that benefit a large number of users are the easiest to justify, so please add a 👍  reaction to issues that matter to you. Like many other GitHub projects, we’ll use these reactions as a simple kind of voting system.

✔︎ We’ll manage issue priority and workflow using ZenHub. If you’re not already familiar, ZenHub adds a number of features to GitHub Issues through its clever browser extension. It allows us to group related issues into epics and to visualize everything via a kanban board. Installing and using ZenHub is by no means a requirement, but do check it out if you’d like to get an additional level of insight about what we’re working on.

✔︎ Issues that are well-suited for community contribution will be labeled help-wanted. Take a look—you’ll see there are already a few there.

✔︎ Pull requests will be acknowledged within a week and reviews of them will be done through GitHub’s built-in pull request reviews. Please continue to follow the contribution guidelines—in a project as large and widely-used as Gradle, it’s crucial to be rigorous and get things right.

Medium-Term Transition

Open JIRA issues will be migrated to GitHub, and no new issues will be put into JIRA after the release of Gradle 3.2. We’ll ask for examples and/or clarification on JIRA issues that are not actionable so that they can be prioritized.

To draw a clearer roadmap, we’ll add and maintain high-level feature epics and mark them with milestones representing future Gradle releases.

Our bugs forum will no longer be necessary and will be made read-only. For general usage questions and potential bugs for which no reproducible test case or build scan can be provided, please continue to use the help/discuss forum.

Long-Term Unity

Once we’ve made the changes detailed above, we’ll continue looking for ways we can open up Gradle ecosystem to even greater community contribution. We’re really excited about this, and we hope you will be too.

We’d love to hear your feedback—let us know what you think in the comments on this post or talk to us @Gradle on Twitter. Your suggestions, questions, and of course, issues are most welcome.

Introducing Composite Builds

It’s not every day that we get to announce a feature that revolutionizes several software engineering workflows, but today is that day. Composite builds, a new feature in Gradle 3.1, enables an entirely new dimension in project organization.

Composite builds are a way to join multiple independent Gradle builds and build them together. The brevity of that statement does not fully convey all of the new possibilities, so let me show you how this will make your life as a developer a lot easier.

Joining projects

Many organizations split their code base into several independent projects, each having a dedicated repository and release cycle. Integration between the projects is managed using binary dependencies, e.g. JAR files published to a binary repository like Artifactory. This approach has many advantages, but can be inefficient when trying to rapidly develop and test changes that affect two or more of these projects at once.

Imagine for a moment that you are fixing a bug in a Java library that your application depends on. Your workflow probably looks something like the following:

  1. Change the library
  2. Publish the library to a local repository
  3. Add the local repository to your application’s repositories
  4. Change your application’s dependency to the new library version
  5. Test your application
  6. Repeat until the problem is fixed or you lose your mind

With composite builds, you can short-circuit this workflow by including the library’s build into your application’s build. Gradle will then automatically replace the binary dependency on the library with a project dependency—meaning that changes you make to the library become available to the application instantaneously:

The same approach works for plugins that your project depends on. You can now include a locally checked-out version of a plugin into your project’s build and get into the same kind of tight development loop between them:

The new includeBuild() API in settings.gradle even lets you write a Gradle build that dynamically includes other builds if they are available on the local file system. You could then import this composite into your IDE and do cross-repository refactoring or debugging.

Splitting Monoliths

Organizations that want to avoid the integration pains of multiple repositories tend to use a “monorepo”—a repository containing all projects, often including their dependencies and necessary tools. The upside is that all code is in one place and downstream breakages become visible immediately. But this convenience can come at the cost of productivity: a given developer will usually work only on a small part of a monorepo, but will still be forced to build all upstream projects, and that can mean a lot of waiting and wasted time. Likewise, importing large monorepo projects into an IDE often results in an unresponsive and overwhelming experience.

With composite builds, you can break your monorepo up into several independent builds within the same repository. Developers can work with the individual builds to get fast turnarounds or work with the whole composite when they want to ensure that everything still plays well together:

If you’re planning to move from a monolithic application to multiple independent ones, composite builds now offer a seamless migration strategy.

This is just the beginning

We plan to add a number of improvements to composite builds in upcoming releases:

  • Targeting tasks in an included build from the command line
  • Richer dependency substitution API with support for custom publications
  • Executing included builds in parallel
  • Integration with Gradle’s continuous build capabilities
  • Out of the box support for composite builds in IntelliJ and Eclipse

Of course, nothing is more important than feedback from real world usage. So please give composite builds a try in your own projects or have a look at the samples. Let us know about any problems, suggestions and cool things you built with it on the Gradle Forum.

Introducing Build Scans

A few months ago at this year’s Gradle Summit conference, we announced a new part of the Gradle platform called Gradle Cloud Services. In this post, I want to introduce you to the first of these services—the Gradle Build Scan Service—and the build scans it makes possible.

What is a build scan?

A build scan is a representation of data captured as you run your build. The Build Scan Plugin does the work of capturing the data and sending it to the Build Scan Service. The service then transforms the data into information you can use and share with others. Here’s a quick example of using a build scan to investigate a failure:

Publishing and Viewing a Build Scan

It’s all about that link! Here—click it for yourself: https://gradle.com/s/a5e3ngolykv3w.

As you can see, the information that scans provide can be a big help when troubleshooting, collaborating on, or optimizing the performance of your builds. For example, with a build scan in the mix, it’s no longer necessary to copy and paste error messages or include all the details about your environment each time you want to ask a question on Stack Overflow or the Gradle Forum. Instead, just include a link to your latest build scan. It contains much, if not all, of the information the person answering your question might need to know. It’ll save you both time, and they’ll probably thank you for it.

Who’s using them?

We’re excited that a number of prominent open source projects like Hibernate and JUnit 5 have already integrated build scans into their workflow. You can take a look through sample scans from each of these projects at gradle.com/explore.

Open Source Gradle Build Scans

Put build scans to use for yourself

If you’re new to build scans, now is a great time to start using them. We’re continually rolling out new features, and we’ll cover each of them in subsequent posts. In the meantime, you can learn how to enable build scans for your existing projects via our getting started instructions, or get up and running with a sample project by cloning our quick start repository and following the steps in its README.

Happy scanning, and we look forward to your feedback!