From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

set the channel description: Any discussions about the recent releases and the features there. This is an addition to the <#CJWG8VDM0|> channel which we use for announcements

<@U04RQ6WGDB7> You will see the reason for this channel soon, I hope :stuck_out_tongue:

set the channel topic: Gradle Build Tool 8.7 Release :rocket:
Overview: <https://gradle-community.slack.com/archives/CJWG8VDM0/p1712921270824479>

<!channel> The Gradle Build  Tool 8.7 release stream is live: <https://youtu.be/YnMAO_2grBQ>

We're experimenting with new formats, so any feedback is welcome!

Would be nice to know who is talking. I mean the name of the person speaking. But that might just be me. :-D

It is a valid point. I added it to my ToDo list for the next release video )

:clap: et :bow:  to <@U023HSZL88M> for becoming the first ever non-Gradle Inc. presenter in the release video. We will be doing it more, and hopefully not just for the Gradle Build Tool core :)

And one of my next video goals is to ensure these videos go live within one week after the release is published

Speaking of the public roadmap, there are some changes there: <https://github.com/orgs/gradle/projects/31>
It is still WiP, but you can see there are now time horizons instead of quarters. The aspirational release milestones and quarters are now available in extra tabs

So, any comments about the features &amp; Co in 8.7?

in Gradle 8.8 release notes - I suppose following is a typo and should be "Since Gradle 8.8 ..."
&gt; Since Gradle 8.7, it's been possible for plugins to define their own dependencies-like block.

From the wording I guess it is supported since 8.7 but was not documented resp. mentioned in the release notes.

In the 8.8 release notes at "New Gradle lifecycle callbacks" links to <https://docs.gradle.org/8.8-rc-1/javadoc/org/gradle/api/IsolatedAction.html|https://docs.gradle.org/8.8-rc-1/javadoc/org/gradle/api/IsolatedAction.html> which says
> This approach ensures that sharing mutable state across targets via any means (including BuildService, which are not supported) is prevented.
> 
But then the example shows how to use shared mutable state across two actions.

What do I get wrong there?

Asked the team behind the feature to take a look. Thanks for the feedback.

Note that the way mutable data sharing is prevented is not by forbidding it, but by creating project-private copies of the data, which is provided for free to isolated actions. Accessing mutable data is allowed, and safe, and the data is guaranteed not to be shared across projects.

Ah, I see, it is per target, that is per project, not per action. 

Makes me shudder by the thought that people *will* then start to use static state to still share state. :-(

was there a change in behavior for `-m` flag? I noticed that its not passed down to included builds

Not sure whether it changed, but at least if the included build builds a plugin you apply, it would probably be fatal if `-m` would be forwarded.

Hey, Gradle team! When do you plan to bring Kotlin 2.0+ to Gradle?

<https://github.com/gradle/build-tool-roadmap/issues/63>

It is a part of Gradle 9.0 scope <https://blog.gradle.org/road-to-gradle-9|https://blog.gradle.org/road-to-gradle-9>

Looks like `LifecycleAwareProject` <https://github.com/gradle/gradle/issues/29187#issuecomment-2268977568|info> is missing in 8.10-RC-1 release notes

Hey Yahor, `LifecycleAwareProject` itself is internal API, the release note entry mentions the change of behavior in `GradleLifecycle.beforeProject` which makes it a suitable replacement for `allprojects`

That's in _Improved behavior and callback execution for the GradleLifecycle API_

image.png

small mistake in the 8.10-RC1 release notes. <https://github.com/gradle/gradle/issues/10867> is included, but it was actually closed as a duplicate.

Thanks for noticing! I've closed the issue as a duplicate properly and that should remove it from the list there =)

I see it's still there in the 8.10 release notes. Maybe it needed to be removed from the milestone too.

The issue is that the milestone is 8.10RC1. I updated this since the duplicate will be fixed in 8.11RC1.

The release notes will be updated a little later.

A typo in the <https://docs.gradle.org/8.10/userguide/upgrading_version_8.html#extending_configurations_in_same_project|migration guide from Gradle 8.9 to 8.10>:
> Deprecated extending configurations in the same project
It should be rephrased as it’s about deprecation of extending configurations from different projects

Could I post a feature request here? Or discuss it?

As you can see from the channel description, this is to discuss recent releases and their features. :wink:

For creating a feature request you should better open a GitHub issue with the Feature Request template

Sorry for necro-posting. Just returning from paternity leave and catching up on the things

Hey <@UER4V36VA>,

Replying here to <https://gradle-community.slack.com/archives/CJWG8VDM0/p1744649899434359?thread_ts=1744191308.410819&amp;cid=CJWG8VDM0|your report / question>

How is Gradle made aware of that added JDK with native image capability on Windows?

Here is the gradle snippet i am using.

```java {
  withSourcesJar()
  withJavadocJar()
  toolchain { configureJvmToolchain() }
}

kotlin {
  jvmToolchain { configureJvmToolchain() }
}

fun JavaToolchainSpec.configureJvmToolchain() {
      languageVersion = toolchainVersion
      nativeImageCapable = toolchainVendor.map { it.matches("graalvm community") }
}```


`toolchainVersion` and `toolchainVendor` is defined as an extension function and configured using gradle version catalog

```//libs.version.toml
[versions]
java                           = "24"
kotlin                         = "2.1.20"
gradle                         = "8.14-rc-1"
java-vendor                    = "GraalVM Community"```

```val Project.javaVersion
  get() = libs.versions.java.asProvider().map { JavaVersion.toVersion(it) }

val Project.toolchainVersion
  get() = javaVersion.map { JavaLanguageVersion.of(it.majorVersion) }

val Project.toolchainVendor
  get() = libs.versions.java.vendor.map(JvmVendorSpec::matching)```

Screenshot 2025-04-15 at 11.53.07 AM.png

As i mentioned, it’s working fine on Github action for all other targets (linux/macos) and failing only for windows.

This is how i install and set the java home on Github action workflow

```      matrix:
        java-version: [ '24' ]
        distribution: [ 'graalvm-community' ]    

  - name: ☕ Setup GraalVM CE Dev Build
        uses: graalvm/setup-graalvm@v1
        with:
          java-version: ${{ matrix.java-version }}
          distribution: ${{ matrix.distribution }}
          github-token: ${{ secrets.GITHUB_TOKEN }}
          cache: 'gradle'
          set-java-home: 'true'
          native-image-musl: ${{ matrix.build-type == 'musl' }}
          native-image-job-reports: 'false'```

So i will make sure `set-java-home: 'true'` is true for the distribution

Ok, nothing stands out.

Could you attempt to run the `javaToolchains` task on that windows runner and report what it outputs?
See <https://docs.gradle.org/current/userguide/toolchains.html#sub:viewing_toolchains|here> for details.

```Run ./gradlew -q :javaToolchains
  
 + Options
     | Auto-detection:     Enabled
     | Auto-download:      Enabled
 + GraalVM Community JDK 24.0.1+9-jvmci-b01
     | Location:           C:\hostedtoolcache\windows\graalvm-community-jdk-24.0.1_windows-x64_bin\24.0.1\x64\graalvm-community-openjdk-24.0.1+9.1
     | Language Version:   24
     | Vendor:             GraalVM Community
     | Architecture:       amd64
     | Is JDK:             true
     | Detected by:        Current JVM
Welcome to Gradle 8.14-rc-1!
Here are the highlights of this release:
 - Java 24 support
 - GraalVM Native Image toolchain selection
 - Enhancements to test reporting
 - Build Authoring improvements
For more details see <https://docs.gradle.org/8.14-rc-1/release-notes.html>
Configuration on demand is an incubating feature.
Type-safe project accessors is an incubating feature.
&gt; Configure project :
w: The artifact `org.jetbrains.kotlin:kotlin-compiler-embeddable` is present in the build classpath along Kotlin Gradle plugin.
This may lead to unpredictable and inconsistent behavior.
Please remove the `org.jetbrains.kotlin:kotlin-compiler-embeddable` artifact from the build classpath.
See <https://kotl.in/gradle/internal-compiler-symbols> for more details.
FAILURE: Build failed with an exception.
* What went wrong:
Could not determine the dependencies of task ':compileKotlin'.
&gt; Toolchain installation 'C:\Users\runneradmin\.gradle\jdks\eclipse_adoptium-24-amd64-windows.2' does not provide the required capabilities: [NATIVE_IMAGE]
* Try:
&gt; Run with --stacktrace option to get the stack trace.
&gt; Run with --info or --debug option to get more log output.
&gt; Get more help at <https://help.gradle.org>.
BUILD FAILED in 43s```

Are you using the daemon toolchain feature? Do you have a `gradle/gradle-daemon-jvm.properties` file in that project?

Because that output makes little sense to me
I don't understand how the toolchain output appears before the Gradle welcome message.

Do you have two Gradle invocations in there?

Yes, using the gradle jvm toolchain
```#This file is generated by updateDaemonJvm
toolchainVersion=24```

Yeah there are two Gradle invocations
```      - name: Native Image Build & Test
        id: native-build
        run: |
          ./gradlew -q :javaToolchains
          ./gradlew nativeCompile ${{ matrix.buildArgs }}```

From what you share, I don't understand what's happening.

Are you able to reproduce this in isolation in a repository you could share?