Add support for Java Toolchains in Quarkus Gradle plugin

[joschi]

Add support for Toolchains for JVM projects to the Quarkus Gradle plugin.

The implementation tries to be close to the one used in the Gradle JavaExec task, assuming this is The Way™ since that isn't always quite clear in Gradle. 😓

Closes #20452

[quarkus-bot]

Thanks for your pull request!

Your pull request does not follow our editorial rules. Could you have a look?

• title should preferably start with an uppercase character (if it makes sense!)
• title should not start with chore/docs/feat/fix/refactor but be a proper sentence

_{This message is automatically generated by a bot.}

[joschi]

@gsmet Maybe you could kindly ping the right people to review the PR? 😇

[gsmet]

Yeah sorry, we are a bit short of reviewers/owners for the Gradle plugin unfortunately. Let's at least see if CI is happy :).

[gsmet]

BTW, if you're willing to contribute in the Gradle area, we have some issues that need fixing and that would help a lot :).

[asodja]

Just passing by:
JavaExec is doing that because for JavaExec you can set java as executable. For your task that doesn't make a lot of sense and objectFactory.newInstance(DefaultJavaExecSpec.class).getExecutable(); will always return null anyway. Also you are referencing internal type, it would be great if you could avoid that :)

I assume you want to achieve logic like:

if (quarkusTask has set toolchain) {
   use that
} else {
  use toolchains from JavaExtension
} 

You can achieve that with something like:

Provider<JavaLauncher> javaExtensionToolchainLauncher = getToolchainService().launcherFor(getJavaPluginExtension().getToolchain());
task.getJavaLauncher().convention(javaExtensionToolchainLauncher);

See also https://docs.gradle.org/current/userguide/toolchains.html#sec:plugins_toolchains

I hope that helps! 👋

[asodja]

Calling .get() will throw exeption if value is null. But launcher here will never be null, since it's not marked as @Optional. And if user sets it to null (they need to also unset convention on the property) then this task will fail already at validation.

What I am trying to say is: It seems in this case you don't need to check launcher != null later on, unless you mark getJavaLauncher() as @Optional @Nested, but then you also need to call .getOrNull() here. But I think it makes more sense that getJavaLauncher() is not allowed to be null and with that you can remove null check later on

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit f672ef4.

Failing Jobs

Status	Name	Step	Failures	Logs	Raw logs	Build scan
✖	Initial JDK 17 Build	Build	Failures	Logs	Raw logs	🔍

You can consult the Develocity build scans.

Failures

⚙️ Initial JDK 17 Build #

- Failing: devtools/gradle/gradle-application-plugin 
! Skipped: integration-tests/gradle 

📦 devtools/gradle/gradle-application-plugin

✖ Failed to execute goal net.revelc.code:impsort-maven-plugin:1.12.0:check (check-imports) on project io.quarkus.gradle.plugin: Imports are not sorted in /home/runner/work/quarkus/quarkus/devtools/gradle/gradle-application-plugin/src/main/java/io/quarkus/gradle/GradleUtils.java