Hi, anybody fit in gradle init scripts (init.grad...

# gradle

[huehnerlady]

Hi,

anybody fit in gradle init scripts (init.gradle.kts)?

I want to enable the kotlin compiler setting allWarningsAsErrors
I do not want that in general, just on my local machine (as this would also fire when there are deprecations)


Currently my file includes:

allprojects {

  afterEvaluate {
    if (tasks.findByName("compileKotlin") == null) {
      logger.lifecycle("[init.gradle.kts] no kotlin project")
    }
    else {
      logger.lifecycle("[init.gradle.kts] adding 'allWarningsAsErrors = true'")
      tasks.withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompile> {
        kotlinOptions {
          allWarningsAsErrors = true
        }
      }
    }
  }
}

When I run my project it is showing the [init.gradle.kts] adding 'allWarningsAsErrors = true' log message, but the warnings do not make the build fail. if I add that flag to the build script, it does fail.

Any idea what I am doing wrong?

[Vampire]

As a start, I'd recommend writing init scripts that should work with all projects in Groovy DSL, otherwise you miss projects that have old Gradle versions where Kotlin DSL init scripts were not yet supported.

Besides that, is that the whole init script? No initscript { ... } block? I'd then expect that script to not even compile for not finding the KotlinCompile class. If you have it, but just left it out, the problem most probably is, that the actual task class added by the Kotlin plugin and the task you check for using withType are coming from different class loaders and thus are different classes, so your configuration block is not executed.

[huehnerlady]

Hi,

Thanks for answering.
Here is my whole file.

What would you suggest I do to achieve my goal? 🙂
I am very new to init files and so maybe I miss something?

I would like to use kotlin dsl, as all our projects have kotlin DSL and so the syntax is not completely different to the usual build scripts 🙂

init.gradle.kts.kt

[Vampire]

Yeah, that's exactly what I said.
The KotlinCompile you check for is not the class the tasks are written in.
If you add to your init script

println(tasks.findByName("compileKotlin")!!::class.java)
println(tasks.findByName("compileKotlin")!!::class.java.superclass)
println(tasks.findByName("compileKotlin")!!::class.java.superclass.classLoader)
println(org.jetbrains.kotlin.gradle.tasks.KotlinCompile::class.java)
println(org.jetbrains.kotlin.gradle.tasks.KotlinCompile::class.java.classLoader)

you will see something like

class org.jetbrains.kotlin.gradle.tasks.KotlinCompile_Decorated
class org.jetbrains.kotlin.gradle.tasks.KotlinCompile
VisitableURLClassLoader(ClassLoaderScopeIdentifier.Id{coreAndPlugins:settings[:]:buildSrc[:]:root-project[:](export)})
class org.jetbrains.kotlin.gradle.tasks.KotlinCompile
VisitableURLClassLoader(ClassLoaderScopeIdentifier.Id{coreAndPlugins:init-file:/D:/Dateien/.gradle/init.d/test.init.gradle.kts(export)})

which shows that the two classes come from different class loaders and thus the withType will not find the ones you like to configure.
Instead use the class of the task you found:

val compileKotlin = tasks.findByName("compileKotlin")
if (compileKotlin == null) {
...
else {
...
tasks.withType(compileKotlin::class) {
...

You also do not need the initscript dependency then.
But as the script does not really know the correct class of the task, you can also not use kotlinOptions like that.
You would then probably need to use reflection to set it.

Again, I strongly recommend you use Groovy DSL for init scripts.
Because due to its ducktyping, kotlinOptions could then be used without problem.
And Groovy DSL and Kotlin DSL should usually be similar enough to not confuse you.
I usually prefer Kotlin DSL for anything, but in case of init scripts, it is just better and more flexible to use Groovy instead.
With Groovy DSL the complete init script would be

allprojects {
    afterEvaluate {
        def compileKotlin = tasks.findByName("compileKotlin")
        if (compileKotlin == null) {
            logger.lifecycle("[init.gradle.kts] no kotlin project")
        }
        else {
            logger.lifecycle("[init.gradle.kts] adding 'allWarningsAsErrors = true'")
            tasks.withType(compileKotlin.getClass()) {
                kotlinOptions {
                    allWarningsAsErrors = true
                }
            }
        }
    }
}

[Vampire]

Btw. you should really think three times before you add mavenLocal() to any build, let alone to every build.
It is broken by design, can easily result in flaky and strangely behaving builds and will also make the builds much slower, especially when added as first repository.

[Vampire]

To test out local versions of things, better use composite builds or if you really need a local repo because of incompatible Gradle versions or the dependency being not built with Gradle, better use a dedicated local repository or at least use a repository content filter to only take exactly what you know is good and expected to be taken from mavenLocal.

[huehnerlady]

Hey, many many thanks for all your help. Maybe I do try out gradle as init script again 🙂

We used to have that in the build script (I know, scary right) and we removed that (thank god). But when I build some dependencies locally I can easily use them in other projects, which I like. So far I did not have any problems, but I always keep in mid if there are weird behaviours to comment the line out as a first try.

I am much of a learner with init scripts and so far I found every little thing very hard to do as it does defer from build scripts. Any hints for me on where to improve and find more documentation about that?
I definitey have a look at the composite builds, thanks for the pointer 🙂

[Vampire]

I don't think there is much special information dedicated to init scripts, as it is basically the same as in build scripts and additionally there are not too much actual use-cases for init scripts as they generally for all builds and most logic of a build should be in its actual build scripts so that the build runs the same everywhere.

[Vampire]

But if you struggle with things, don't hesitate to ask for example in this Slack, there should usually be someone around able to help.

[huehnerlady]

thank you very very much 👍🏻

[huehnerlady]

I also tested your way and it works, so many thanks for that 🙂

[Vampire]

Oh, I thought we are in the Gradle slack.
Actually this is usually dedicated to using Kotlin in Gradle scripts.
So for general things about Gradle, the Gradle Community Slack is usually the better place to ask.
Just have a look at the channel topic here, there you find a link.

[huehnerlady]

Thanks 🙂