This message was deleted.

This should do it:

tasks.withType<KotlinCompile>().configureEach {
    kotlinOptions {
        jvmTarget = "17"
    }
}

Does that affect the target that Gradle itself uses? i.e. I thought that affects how your Kotlin code is compiled, not how Gradle compiles the Kotlin code from the script.

yes. any Kotlin compilation will use that. You can target a specified task if need be:

tasks.named<KotlinCompile>("compileKotlin") {
    kotlinOptions {
        jvmTarget = "17"
    }
}

The OP is asking about doing it without the

kotlin-dsl

plugin though.

hmmm. Unclear if OP is asking for Gradle kts (plugins, scripts, etc) or for a Kotlin app/lib. If there is anything of significance for Gradle build (build-logic composite include, etc) should be using

kotlin-dsl

. Definitely don’t want to mix

kotlin-dsl

into a Kotlin app/lib, that causes all manner of problems.

Maybe just including a

compileOnly

dependency on

gradleKotlinDsl()

is enough? That's what

kotlin-dsl

does

No, definitely don’t do that. Kotlin DSL depends on Gradle’s embedded Kotlin version, which is likely different than used for Kotlin app/lib, causing all manner of problems.

So a Kotlin gradle script for a Kotlin app/lib can't change the jvmTarget from 1.8?

Yes. That’s this snippet:

configure<KotlinDslPluginOptions> {
    jvmTarget.set("17")
}

So the offending inline function call should be moved to a plugin or task, and that project should set the target to 17 with

kotlin-dsl

applied?

OP nowhere mentioned anything about Gradle logic. I'd say Chris first answer was exactly what he is after from what he asked. If you do develop Gradle logic and change the jvm target to anything but what

kotlin-dsl

sets by default, you have to be aware that you are effectively raising the minimum Java version needed to run the Gradle build to that version which usually is highly undesireable.

I'm assuming it's about gradle logic because they specifically asked about not applying

kotlin-dsl

.

usually is highly undesirable

So it would be fine if it were an internal app that is already committed to using that version of Java?

The important distinction is, the Java you use for your production code, vs. the Java you use for running Gradle. If you do that to Gradle logic, all builds that use this Gradle logic has to be run with at least that Gradle version, independent from what you use for your production code. Optimally you use the JVM toolchains feature to also separate this for your builds. But yes, if it is internal build logic and everyone and everything running these builds runs them with at least that Java version and that Java version is supported by your Gradle version for running Gradle, it should be fine I think.

I'm assuming it's about gradle logic because they specifically asked about not applying

kotlin-dsl

.

I'm assuming it is not about Gralde logic because they specifically asked about nto applying

kotlin-dsl

. What should be the problem to apply if it is for Gradle logic? For me it makes more sense that it is for non-Gradle logic bug by googling OP just found solutions involving

kotlin-dsl

which he does not want to use as it is not for Gradle logic.

A project can’t be both a Gradle Kotlin DSL/plugin (

kotlin-dsl

) AND a Kotlin app/lib (

kotlin("jvm")

) at the same time.

So this is pretty much what I was trying to do but that doesn't work

I'm assuming it is not about Gralde logic because they specifically asked about nto applying

kotlin-dsl

.

What should be the problem to apply if it is for Gradle logic?

It is for Gradle logic but is a problem because of the above But this is for internal use only anyway so I'll try the solution posted while keeping your warning in mind 🙂 Thanks for your help

if it’s for Gradle logic, remove

kotlin("jvm")

and use

kotlin-dsl

. Doable?

No, because it is for a Kotlin app so can't remove that

Perhaps move the Gradle logic to build-logic included project (or the older buildSrc). That way you can separate the Gradle logic / build from the app build.