Andrew Lethbridge
01/27/2023, 11:30 PMplugins {
kotlin("jvm") version "1.7.20"
id("companyName-java-gradle-plugin")
}
Everything up to this point works fine, no issues whatsoever.
I recently added Kotlin as a top level language in this convention plugin so I am able to switch my plugin block to
plugins {
id("companyName-kotlin-gradle-plugin")
}
This required me to add the Jetbrains Kotlin plugin as an implementation dependency in my own build script vs getting that code from the plugins block and Gradle plugin portal.
implementation("org.jetbrains.kotlin:kotlin-gradle-plugin:1.7.20")
I am applying the plugin internally like so
class InternalKotlinPlugin : Plugin<Project>
{
override fun apply(project: Project) {
project.plugins.apply(KotlinPlatformJvmPlugin::class.java)
// other convention logic.
}
}
This all seems to work fine from a compilation perspective but the addition of that dependency seems to have changed my buildscript classpath and I am seeing weird issues at runtime which leads me to believe its a classpath issue, but I haven’t proven this to be true yet.
My ultimate question is:
Is there any fundamental difference in the buildscript classpath between
plugins {
kotlin("jvm") version "1.7.20"
}
vs
plugins {
id("companyName-kotlin-gradle-plugin")
}
Where that custom plugin has an implementation dependency against the Kotlin plugin and is applying it via a class reference instead of the buildscript DSL?