Configure languageVersion via toolchain#5735
Conversation
Codecov Report
@@ Coverage Diff @@
## main #5735 +/- ##
=========================================
Coverage 84.66% 84.66%
Complexity 3833 3833
=========================================
Files 548 548
Lines 13058 13058
Branches 2302 2302
=========================================
Hits 11056 11056
Misses 868 868
Partials 1134 1134 Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
3flex
left a comment
There was a problem hiding this comment.
I did something very similar in #5676 and reverted in #5685 because:
The original PR only was only half a solution - it meant that all builds effectively ran on Java 1.8 regardless of which Java version the Gradle build was running. This is fine for the main source build but not for tests, which we want to run on multiple Java versions.
If you can make updates to allow for that then I'd be happy to approve but there'll likely be config changes to a few places in the build and potentially the GitHub workflows as well.
|
I was noticing that too, the solution might be Build on latest Java, test through lowest Java, but there is a CompilerTest > with a source file that contains violations() FAILED
java.lang.NoSuchMethodError: 'void org.jetbrains.kotlin.cli.common.arguments.K2JVMCompilerArguments.setSingleModule(boolean)'
at app//com.tschuchort.compiletesting.KotlinCompilation$commonK2JVMArgs$1.invoke(KotlinCompilation.kt:359)
at app//com.tschuchort.compiletesting.KotlinCompilation$commonK2JVMArgs$1.invoke(KotlinCompilation.kt:300)
at app//com.tschuchort.compiletesting.AbstractKotlinCompilation.commonArguments(AbstractKotlinCompilation.kt:133)
at app//com.tschuchort.compiletesting.KotlinCompilation.commonK2JVMArgs(KotlinCompilation.kt:300)
at app//com.tschuchort.compiletesting.KotlinCompilation.compileJvmKotlin(KotlinCompilation.kt:488)
at app//com.tschuchort.compiletesting.KotlinCompilation.compile(KotlinCompilation.kt:664)
at app//io.github.detekt.compiler.plugin.util.CompilerTestUtils.compile(CompilerTestUtils.kt:21)
at app//io.github.detekt.compiler.plugin.CompilerTest.with a source file that contains violations(CompilerTest.kt:11) |
|
The |
# Conflicts: # build-logic/src/main/kotlin/module.gradle.kts
|
Disabled. Let's see the impacts on build time. |
|
Yeah that was going to be my next point, but I wanted to see the actual CI runtimes first. They're not good (which is expected). The loss of parallelism for test execution on the different JVM versions really hurts. This tradeoff isn't worth it just to use toolchains. |
+1 for this. I'd rather keep explicit Java versions in the CI matrix as it's also easier for users to understand which version of Java broke |
|
Agreed, I'll leave this PR open until we find a new way to optimize, for the same reason, there is a regression of using toolchain in pinterest/ktlint#1787. |
# Conflicts: # .github/workflows/pre-merge.yaml # build.gradle.kts
|
It looks fine for now. |
|
|
||
| plugins { | ||
| id("com.gradle.enterprise") version "3.12.4" | ||
| id("org.gradle.toolchains.foojay-resolver-convention") version "0.4.0" |
There was a problem hiding this comment.
For Windows, check https://github.com/detekt/detekt/actions/runs/4464478367/jobs/7840655669
There was a problem hiding this comment.
It's not needed for Windows specifically, it's required any time a requested JDK is not found locally. It's a requirement in most cases if using toolchains.
More here: https://docs.gradle.org/current/userguide/toolchains.html#sub:download_repositories
# Conflicts: # build-logic/src/main/kotlin/module.gradle.kts # detekt-gradle-plugin/settings.gradle.kts
|
Is this PR still blocked? Could we make a call on whether to move forward or to close this? |
|
My 2 c here: I'd love us to use |
|
I'm going to close this, though not because of the foojay plugin (that's essentially a requirement to use toolchains outside of controlled environments where JDKs are all pre installed). Instead I'd like to wait until this is ready later this year: gradle/build-tool-roadmap#61 We can then just use a standard config to set up the test suites instead of developing a custom one. Things are working ok as they are so there's no real reason to switch yet. |
Follow up #5614.
https://kotlinlang.org/docs/gradle-configure-project.html#gradle-java-toolchains-support
https://jakewharton.com/build-on-latest-java-test-through-lowest-java