is anyone out there familiar with this issue? <htt...

# gradle

[wakingrufus]

is anyone out there familiar with this issue? https://github.com/Kotlin/dokka/issues/1463 I am running into a situation where code like

target.plugins.withId("kotlin") { target.extensions.configure<KotlinProjectExtension>("kotlin") }

results in a

Caused by: java.lang.BootstrapMethodError: java.lang.NoClassDefFoundError: org/jetbrains/kotlin/gradle/dsl/KotlinProjectExtension

and I am trying to wrap my head around it and find a fix. i feel like the kotlin plugin might being doing weird stuff with classloaders?

[Vampire]

How do you declare a dependency on the kotlin plugin in the build of your plugin?
How / where do you apply your plugin?
How / where do you apply the Kotlin plugin?

Sidenotes: Project#plugins JavaDoc says you shouldn't use it but Project#pluginManager and you should use the proper current ID of the plugin you check for. If it works with kotlin that is probably just for backwards compatibility, but the current ID should be a different one I think.

[wakingrufus]

kotlin is the id of the base kotlin plugin, and then there are other plugins on top of it for jvm, multiplatform, etc

[wakingrufus]

i am using the plugins {} syntax to apply them

[wakingrufus]

and i tried both in the project and settings.gradle, same issue

[wakingrufus]

so far t he only solution i have found is to put the kotlin plugin on the classpath of my plugin. but then downstream projects are restricted from upgrading their kotlin plugin beyond the version my plugin dpends on

[wakingrufus]

trying pluginManager now...

[wakingrufus]

same issue

[Vampire]

Of course same issue, that was just a sidenote. ;-)
Even the base plugin should have another id. Something with namespace. Only built-in plugins should use IDs without namespace.

Regarding my actual questions for the issue, unfortunately you didn't really answer them in a helpful way. Let me ask differently. From your answer I guess you have the Kotlin plugin only as compileOnly? Regarding where you apply, I didn't mean syntax-wise. If you for example apply your plugin in the root project and some sub projects, but the Kotlin plugin only in some sub projects, your plugin cannot find the motion plugins classes as they are lower in the classloader hierarchy. Or if you add your plugin as buildSrc dependency or even have it in there and apply the Kotlin plugin in your root project, same problem. ...

[wakingrufus]

my plugin only has compileOnly dep on the kotlin plugin, but in the project using these plugins, it is applying both the kotlin plugin and my plugin via the plugins {} block in the project buildscript

[wakingrufus]

my plugin is in our maven repo, so it is fetched from there

[Vampire]

Hm, sounds like it should work.
Can you please debug the execution and look at the class loaders of your plugin class and the KotlinProjectExtension class?
What is their string representation?

[wakingrufus]

ok, ill look at that next. thanks

[wakingrufus]

im also going to look into the id thing. although i dont think that should effect the classpath, unless the kotlin plugin is dynamically adding things to the classpath or something 🤔

[Vampire]

No, the id thing will not change your problem, hence was also just a sidenote.
It is just unclean to use these old obsolete plugin IDs that are only there for backwards compatibility.

[Vampire]

kotlin is not some base plugin.
It is simply the old obsolete name of org.jetbrains.kotlin.jvm

[wakingrufus]

yeah i see. i think it was a base plugin id at one time. but looking at latest source i see that is not the case now