Gradle 4.1-rc-1 is now available for testing

News Build Tool
1

The Gradle team is pleased to announce the first release candidate for Gradle 4.1.

First and foremost, we are excited to announce the new Worker API for Gradle plugins, which facilitates safe parallel execution. We encourage plugin authors to read the new user guide section and implement tasks using this API because it provides parallel execution by default. Core plugins will adopt this API in future releases. Furthermore, the Gradle plugin for Android 3.0 alpha has already adopted this API, so plugin developers will be in good company. More details are given in the full release notes.

This release supports running Gradle on the most recent JDK 9 release (b170+). Read our guide to building Java 9 modules to learn how to produce and consume Java 9 modules with Gradle.

Steady progress has been made to make the build cache more user-friendly. Remote build cache results are mirrored locally and build cache resolution failures no longer fail the build.

Included in this release, Gradle Kotlin DSL v0.10.3 comes with the latest Kotlin release (1.1.3), a new kotlin-dsl plugin for Gradle Plugins written in Kotlin, plus many improvements to usability, stability, and performance.

We’ve also spent some time making composite builds work more like multi-project builds. Included builds are now executed in parallel by default and Gradle avoids executing included build tasks multiple times when possible. Finally, you can now use --continuous build and composite builds together.

Scala enthusiasts rejoice! Scala compile and Scaladoc tasks now support Gradle’s build cache. Zinc has been also upgraded to v0.3.15, which has preliminary support for compiling Scala using Java 9.

Finally, the CLI now shows more detail about tests in-progress, showing which tests are running in parallel.

gradle-4 1-test-exec
28283605-0882ca64-6ae3-11e7-8ea5-c0faf7322722.gif1280Ă—474

More information is available in the full release notes. We hope you will build happiness with Gradle 4.1, and we look forward to your feedback via Twitter or on GitHub.

Upgrade Instructions

Switch your build to use Gradle 4.1 RC1 quickly by updating your wrapper properties:

./gradlew wrapper --gradle-version=4.1-rc-1

Standalone downloads are available at https://gradle.org/release-candidate.

Reporting Problems

If you find a problem with Gradle 4.1 RC1, please file a bug on GitHub Issues adhering to our issue guidelines. If you’re not sure you’re encountering a bug, please use the forum.

3 
<====---------> 33% EXECUTING [2m 11s]
> :foo:test > 85 tests completed
> :foo:test > Executing test foo.BarSpec
> IDLE
> IDLE

would be nicer than

<====---------> 33% EXECUTING [2m 11s]
> :foo:test > 85 tests completed
> IDLE
> IDLE
> :foo:test > Executing test foo.BarSpec
4

Gradle 4.1-rc-1 causes a build failure in case of specific configuration of the spring-boot-gradle-plugin 1.5.4.RELEASE RepackageTask.

See this issue.

Execution failed for task ':foo:bar:bootRepackage'.
> Attempted to resolve configuration ':foo:bar:runtime' that has been resolved previously.

TL;DR: The following snippet causes the failure.

allprojects { Project theProject ->
    theProject.tasks.withType(RepackageTask, { RepackageTask task ->
        // https://github.com/spring-projects/spring-boot/issues/1113
        task.classifier ='repack'
    })
}

This isn’t meant as a “please fix this” but as a “you should probably mention this in the Known Issues section of the release notes”.

Update: gradle idea also won’t work if spring-boot plugin is applied.

5

Based on Andy Wilkinson’s comment Spring Boot does not support Gradle 4.0 yet. We usually don’t document issues in external plugins. From my perspective that should be done by the plugin author.

6

I just informed both involved parties before the release of Gradle 4.1. That’s the most I can do.

I consider the spring-boot-gradle-plugin quite important and assume lots of people are using it.
It is the way to develop a spring-boot application, after all.

One option to circumvent this problem on your side would be to display a deprecation warning about resolving a configuration more than once instead of suddenly exploding in a .1 release… but I have no idea how feasible such a change would be at this point.

I also don’t understand why resolving a configuration twice would be such a big issue, justifying a build failure.

This is probably naive but shouldn’t it be fine to simply return the same already resolved configuration instead?

7

It might be a regression in Gradle. Let’s discuss further here.

1 Like