Hi all, with `Groovy` we had a chance to create `common.gradle` script in order to avoid boilerplate...

# gradle

[nuhkoca]

Hi all, with Groovy we had a chance to create common.gradle script in order to avoid boilerplate and use it within other mutual gradle files. However, I am unable to do have the same behaviour with DSL. Anyone know how to do that?

[louiscad]

You mean Kotlin DSL? I put shared logic in buildSrc/kotlin/main

[louiscad]

That implies moving buildscript classpath dependencies to buildSrc as implementation.

[nuhkoca]

@louiscad Yes I do. If you mean managing dependencies and versions I already do that, I mean applying configs from another gradle file like

apply from : "$rootDir/common.gradle.kts"

This seems not to work in Kotlin DSL

[louiscad]

I'm doing the same for configs. You can also make light plugins in buildSrc, or apply groovy base gradle scripts. Applying gradle kts scripts doesn't work well (not sure if it's even supported).

[nuhkoca]

I see, thanks for informing! Any useful link for how to make a plugin in buildSrc?

[louiscad]

https://guides.gradle.org/writing-gradle-plugins/

[louiscad]

I believe writing a plain something.gradle.kts file like you would write a build.gradle.kts file produces an implicit plugin named something that you can apply using the plugins DSL, or the apply function. You can try and tell if it works

[nuhkoca]

Thanks! I already got my hands dirty. Wrote a .kts file inside src/main/kotlin and added it to my child .kts

However, I am getting below error;
The 'java' plugin has been applied, but it is not compatible with the Android plugins.

Actually I know the reason but I don’t understand why things don’t work like in Groovy.

This is my plugin - common-library.gradle.kts

plugins {
    `java-library`
}

val javaVersion: JavaVersion by extra { JavaVersion.VERSION_1_8 }

java {
    sourceCompatibility = javaVersion
    targetCompatibility = javaVersion
}

dependencies {}

And this is the child

plugins {
    `common-library`
    id(Plugins.androidApplication)
    kotlin(Plugins.kotlinAndroid)
    kotlin(Plugins.kotlinAndroidExtension)
    kotlin(Plugins.kotlinKapt)
}

[louiscad]

java-library applies the java plugin, that's why. You need to stop applying common-library for android modules

[nuhkoca]

So this means that there is no accurate way to overcome?

[gildor]

Just apply android plugin

[gildor]

Also, instead of applying a plugin, just add it to dependencies of your buildSrc and configure required part (but you don't have static accessors in this case)

[gildor]

One more approach is to define function in buildSrc which configures something and call it from your plugin

[gildor]

Also gradle.kts scripts (not plugins) also work same way as Groovy, but problem that it's very not easy to use them, because every config inside uses dynemaic types and sometimes you just don't have access to required classes, but it still possible to use them to configure project itself or built-in plugins, but not third party plugins, because you don't have access to classpath of plugin

[efemoney]

… @gildor unless you add those third party plugins as dependencies of the entire build via dependencies { ... } in buildSrc/build.gradle(.kts). Then the classes are available in your buildscript classpath and you can use them in any build.gradle(.kts). Its still going to be dynamic however so not entirely convenient

[gildor]

@efemoney Yes, correct, I mentioned it above. Essentially buildSrc is the only way to have static types for some additional shared logic in Gradle

[gildor]

Its still going to be dynamic however so not entirely convenient

precompiled script plugins solve this problem