Grails 7: Consider Gradle Java Toolchain to set Vendor in addition to sdkmanrc files

[jamesfredley]

Issue description

We currently use Gradle toolchains to set the Java version, since this is the recommended approach in Gradle 8. We could also use Gradle toolchains to set the vendor, if we desired and it would be complimentary to sdkmanrc with the following benefits:

• does not require sdkman, but is compatible with sdkman installed JDKs
• automatic download, only when the jdk is missing from all of the normal locations, including sdkman
• works with every project using Gradle

settings.gradle (yes it only works there), after any pluginManagment block and not in it. This provides automatic download for all common jdks, versions and operating systems.

plugins {
    id "org.gradle.toolchains.foojay-resolver-convention" version "0.8.0"
}

without foojay-resolver-convention the build will fail, if a JDK meeting the languageVersion and vendor settings is not present.

then in build.gradle:

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(17)
        vendor = JvmVendorSpec.BELLSOFT
    }
}

There will be a false error message the first run, after download, but it runs fine and is gone the next time. Invalid Java installation found at ...

jdks live in .gradle/jdks in user home

https://docs.gradle.org/current/userguide/toolchains.html#sec:auto_detection By default, Gradle automatically detects local JRE/JDK installations so no further configuration is required by the user. The following is a list of common package managers, tools, and locations that are supported by the JVM auto-detection. JVM auto-detection knows how to work with:

• Operation-system specific locations: Linux, macOS, Windows
• Package Managers: Asdf-vm, Jabba, SDKMAN!
• Maven Toolchain specifications
• IntelliJ IDEA installations

[jamesfredley]

Need to understand how this works with matix.java in github actions.

[jamesfredley]

I am closing this due to: https://www.google.com/search?q=does+gradle+toolchain+override+github+action+java+matrix+version&oq=does+gradle+toolchain+override+github+action+java+matrix+version&gs_lcrp=EgZjaHJvbWUyBggAEEUYOTIGCAEQLhhA0gEJMTU3NTNqMGoxqAIAsAIA&sourceid=chrome&ie=UTF-8

Yes, the Gradle toolchain configuration overrides the Java version specified in the GitHub Actions matrix. Here's why: How it works: GitHub Actions Java Matrix: This feature allows you to test your project against multiple Java versions. It installs the specified JDKs and sets the JAVA_HOME environment variable accordingly. Gradle Toolchain: This feature allows you to specify the JDK used for compilation and testing within your Gradle build script. It gives you more fine-grained control over the Java version used. Priority: If you configure a Gradle toolchain, it takes precedence over the JAVA_HOME environment variable set by the GitHub Actions matrix. This means that even if your matrix specifies Java 8, but your Gradle toolchain specifies Java 11, your build will use Java 11. Example: Code

GitHub Actions workflow

jobs: build: runs-on: ubuntu-latest strategy: matrix: java: [8, 11] steps: - uses: actions/checkout@v3 - uses: actions/setup-java@v3 with: java-version: ${{ matrix.java }} distribution: 'temurin' - uses: gradle/wrapper-validation-action@v1 - run: ./gradlew build In this example, even though the matrix specifies Java 8 and 11, if your build.gradle file contains a toolchain configuration that specifies Java 17, the build will use Java 17 for both matrix runs. Benefits of using Gradle toolchain: Consistency: Ensures that you're always using the intended JDK for your project, regardless of the environment. Flexibility: Allows you to specify different JDKs for different tasks within your build. Control: Gives you more control over the build process compared to relying on environment variables.