I often use supplementary .gradle files to apply standard behavior that subprojects can use or not as appropriate. For example I might have a
gradle/publishing.gradle with all the config for the Bintray plugin, a
gradle/junit.gradle with all the config for testing, etc. If a sub-module needs that behavior I can include it with
apply from: "$rootDir/gradle/publishing.gradle.
I’m attempting to port my project’s build to the Kotlin DSL and finding it almost impossible to follow this pattern. Problems I’m running into are:
- If I add the plugin in the sub-project’s
build.gradle.ktsthe included files can’t reference the plugin’s classes or DSL extensions.
- If I add the plugin using a
pluginsblock in the included file, the same is true.
- If I create a
buildscriptblock in the included file with a classpath dependency on the plugin then apply the plugin by class (e.g.
apply<NebulaKotlinPlugin>()) I can reference classes and get the DSL to work but I can’t override config in a particular subproject (e.g. referencing an external lib’s documentation URL in Dokka config) because then the subproject
build.gradle.ktscan’t reference the DSL/classes of the plugin.
- If I apply the plugin or use a
buildscriptblock in both the
build.gradle.ktsand the included file the scripts compile but fail at runtime as the plugin’s classes are loaded with separate classloaders.
Is there actually a way to do this? I’ve looked at the
modularity sample in the kotlin-dsl repo but it doesn’t deal with plugins.
I don’t think I can be the only person who’d want to do such a thing. The only alternatives seem to be copy-pasting common config into every sub-project’s
build.gradle.kts or applying everything in a
subprojects block in the root
build.gradle.kts which assumes every subproject needs all the same things.