I'm setting up a multi-module Gradle project based on Kotlin for the JVM. Since the root project does not contain any code, the Kotlin plugin should only be applied to subprojects.
build.gradle.kts
(root project)
plugins {
kotlin("jvm") version "1.6.20" apply false
}
subprojects {
apply(plugin = "kotlin")
group = "com.example"
repositories {
mavenCentral()
}
dependencies {}
kotlin {
jvmToolchain {
check(this is JavaToolchainSpec)
languageVersion.set(JavaLanguageVersion.of(11))
}
}
}
Trying to set a toolchain causes the build to fail at the kotlin {...}
extension:
Unresolved reference. None of the following candidates is applicable because of receiver type mismatch:
public fun DependencyHandler.kotlin(module: String, version: String? = ...): Any defined in org.gradle.kotlin.dsl
public fun PluginDependenciesSpec.kotlin(module: String): PluginDependencySpec defined in org.gradle.kotlin.dsl
It works fine if I copy the extension definition to each subproject build script, but why isn't it available in the main script?
This is one of my favourite things to fix in Gradle, and really shows off the flexibility that's possible (as well as demonstrating why Gradle can be complicated!)
First I'll give a bit of background info on the
subprojects {}
DSL, then I'll show how to fix your script, and finally I'll show the best way to share build logic with buildSrc convention plugins. (Even though it's last, I really recommend using buildSrc!)Composition vs Inheritance
Using
allprojects {}
andsubprojects {}
is really common, I see it a lot. It's more similar to how Maven works, where all the configuration is defined in a 'parent' build file. However it's not recommended by Gradle.(It's probably common because it's easy to understand - it makes Gradle work more like Maven, so each project inherits from one parent. But Gradle is designed for composition. Further reading: Composition over inheritance: Gradle vs Maven)
Quick fix: 'Unresolved reference'
The error you're seeing is basically because you haven't applied the Kotlin plugin.
The
kotlin { }
configuration block is a very helpful extension function that is loaded when the Kotlin plugin is applied. Here's what it looks like:So if we don't have the extension function, we can just call
configure
directly, and thus configure the Kotlin extension.However, even though this works, using
subprojects {}
has problems. There's a better way...buildSrc and Convention Plugins
buildSrc
is, basically, a standalone Gradle project, the output of which we can use in the main project's build scripts. So we can write our own custom Gradle plugins, defining conventions, which we can selectively apply to any subproject in the 'main' build.(This is the key difference between Gradle and Maven. In Gradle, a subproject can be configured by any number of plugins. In Maven, there's only one parent. Composition vs Inheritance!)
The Gradle docs have a full guide on setting up convention plugins, so only I'll briefly summarise the solution here.
1. Set up
./buildSrc
Create a directory named
buildSrc
in your project root.Because
buildSrc
is a standalone project, create a./buildSrc/build.gradle.kts
and./buildSrc/settings.gradle.kts
files, like usual for a project.In
./buildSrc/build.gradle.kts
,kotlin-dsl
pluginNote that I've used the Maven artifact repository coordinates for the Kotlin Gradle plugin, not the plugin ID!
You can also add other dependencies into
./buildSrc/build.gradle.kts
if you like. If you wanted to parse JSON in a build script, then add a dependency on a JSON parser, likekotlinx-serialization
.2. Create a convention plugin
Create your Kotlin JVM convention that you can apply to any Kotlin JVM subproject.
Don't forget to add the
package
declaration! I've forgotten it a few times, and it causes errors that are hard to figure out.3. Applying the convention plugin
Just like how Gradle plugins have IDs, so do our convention plugins. It's the package name + the bit before
.gradle.kts
. So in our case the ID ismy.project.convention.kotlin-jvm
We can apply this like a regular Gradle plugin...
(Convention plugins can also import other convention plugins, using
id("...")
)Also, since we're using Kotlin, there's an even nicer way. You know how there are included Gradle plugins, like
java
andjava-library
. We can import our convention plugins the same way!Note the backticks around the plugin ID - they're needed because of the hyphen.
(caveat: this non-
id("...")
way doesn't work insidebuildSrc
, only in the main project)Result
Now the root
./build.gradle.kts
can be kept really clean and tidy - it only needs to define the group and version of the project.Because we're using convention plugins and not blanket
subprojects
, each subproject can be specialised and only import convention plugins that it needs, without repetition.Site note: sharing repositories between
buildSrc
and the main projectUsually you want to share repositories between
buildSrc
and the main project. Because Gradle plugins are not specifically for projects, we can write a plugin for anything, includingsettings.gradle.kts
!What I do is create a file with all the repositories I want to use...
(the name,
repositories.settings.gradle.kts
, isn't important - but naming it*.settings.gradle.kts
should mean IntelliJ provides suggestions, however this is bugged at the moment.)I can then import this as a plugin in the other
settings.gradle.kts
files, just like how you were applying the Kotlin JVM plugin to subprojects.