what's the difference between the two? (Except the...

# gradle

[elect]

what's the difference between the two? (Except the first one defines for a single task and the latter for multiple ones)

named<KotlinCompilationTask<*>>("compileKotlin") { 
    compilerOptions { } 
}
withType<KotlinCompile<*>>().all {
    kotlinOptions { }
}

I'm looking to set things such as opt-in, language version, etc

[Javier]

compileKotlin is only configuring that specific task, if there are more compile kotlin tasks the shouldn’t be configured. The second one is configuring all tasks which extend that class

[elect]

Yeah, and other than that?

[Javier]

If you check the IDE gradle tasks window you will see there are multiple compile kotlin tasks

[Javier]

for tests

[Javier]

KMP has more too if i remember correctly

[Javier]

so I am not sure if you get the same behavior doing withType as you can do:

tasks.compileKotlin { … }
tasks.compileKotlinTest { … }

[Vampire]

Two notable differences are, that you use the old kotlinOptions vs the new recommended compilerOptions, and that by using withType<...>().all { ... } like when using withType<...> { ... } you are destroying task-configuration avoidance for those tasks and should instead do withType<...>().configureEach { ... }.

[Javier]

IMO withType<>{} should use configureEach under the hood

[Javier]

For non Gradle expert it can be a problem to know these details

[Javier]

Even for people which work with Gradle, I do some search when I work in my plugins to check if I forgot some configureEach some times

[Vampire]

Yes, but that will break builds out there as withType<> {} was there before the lazy APIs existed and thus cannot be changed backwards compatibly.

[Javier]

Hope Gradle 9 do that even breaking backwards compatibility, if not Gradle will be hard for newbies

[Vampire]

I don't really think it will.
You cannot really deprecate it. And simply changing the behavior will be bad.
You would probably need to deprecate the whole method and instead provide some other or none.

But besides that, the non-lazy is currently basically just relevant for task collections. Most other collections are not really used lazily anyway.

[Vampire]

You can even break things.
I remember one change where they did something lazily and then the functionality did not work anymore at all, because the container was then never queried for the values.

[tapchicoma]

My 2 cents - kotlinOptions is semi-deprecated, better to use compilerOptions. Actually in 1.9.0 it will expose optIn and progressive options while kotlinOptions not.

And in 1.9.0 project level DSL for "org.jetbrains.kotlin.jvm" plugin is coming based on `compilerOptions`:

kotlin {
    compilerOptions { ... }
}

[elect]

nice to read that
ps: how may one discover what is becoming deprecated?

[tapchicoma]

it is not so easy to deprecate 😅 Hopefully in 1.9.20 I will add @Deprecated to it

[tapchicoma]

but it will stay for a long time as too many SO answers or posts has kotlinOptions in code snippets

[Vampire]

chore: edit them 😄

[tapchicoma]

ain't got time for that 😅

[Vampire]

Perfect job for the next intern 😄