https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
f
What gradle version are you on?
m
DUDE WASSUP
8.2! Is the toolchain resolver plugin thing required?
f
👋 👋
8.2 damn I’m jealous
We just set it with
Copy code
java {
            toolchain {
                languageVersion.set(javaVersion.toJavaLanguageVersion())
            }
        }
But it looks like you are trying to set different versions for kotlin?
You should just have to set it on the java plugin and kotlin should pick it up
AGP won’t pick it up until 8.1-alpha something or other
m
Lemme try that - but it failed by just setting the java plugin too, although we're trying to run this on a JDK 17 compatible CI node
v
If you only set it on the Kotlin extension then you get the mismatch, correct. Just set it on the Java extension and nothing on the Kotlin extension and Kotlin will automatically pick it up and no mismatch will happen. If that does not work, please show a reproducer. 🙂
Is the toolchain resolver plugin thing required?
Depends. If you want to do auto-provisioning, yes. If you give toolchain locations manually, or just use the detection of installed toolchains, the plugin is not necessary.
👍 1
m
Dope, thanks for the additional clarification - looks like I just needed to actually read the docs instead of skimming them
👌 1
If I understand correctly, configuring the 
JavaPluginExtension
like so for each project should set the JDK for both compileJava and compileKotlin tasks:
Copy code
extensions.findByType<JavaPluginExtension>()?.toolchain {
              languageVersion.set(JavaLanguageVersion.of(17))
            }
But I'm seeing different behavior:
Copy code
* What went wrong:
Execution failed for task ':home-shared:decoration:compileDebugKotlin'.
> 'compileDebugJavaWithJavac' task (current target is 11) and 'compileDebugKotlin' task (current target is 17) jvm target compatibility should be set to the same Java version.
  Consider using JVM toolchain: <https://kotl.in/gradle/jvm/toolchain>
It's like the 
compileKotlin
tasks are picking up my local 
JAVA_HOME
but the 
compileJava
tasks aren't
I'm currently doing this in a 
subProjects {...
block (ugly, I know) because reasons - should I configure this on a per-module plugin level?
I have a reproducer but the project itself is mad big - lemme make a smaller one to test out
😄 1
@Adam
👍 1
v
If I understand correctly, configuring the 
JavaPluginExtension
like so for each project should set the JDK for both compileJava and compileKotlin tasks:
If you found the extension and actually configured it, yes. You might be better off to either apply the java plugin and then get the extension, failing if it is absent, or using 
pluginManager.withPlugin
to react to the plugin that adds the extension being applied. With the code you showed, you depend on the plugin being applied before that code runs which for example is bad practice if you do it in a plugin as they should be written in order-independent manner. 
compileDebugJavaWithJavac
sounds like we are talking about an Android build. Android builds could again be majorly different as @Frederik Lohner mentioned above.
I'm currently doing this in a 
subProjects {...
block (ugly, I know)
It's not just ugly. It introduces project coupling which is bad for various reasons, so you should really make convention plugins instead. 😉
9 Views
Open in Slack
PreviousNext
Powered by