Is it an unexpected use case to write extension-functions for a plugin's classes in `buildSrc`? I'm ...

# gradle

[darkmoon_uk]

Is it an unexpected use case to write extension-functions for a plugin's classes in buildSrc?
I'm hitting unexpected trouble quite early on 🧵 👉

[darkmoon_uk]

I wanted to make some support functions in buildSrc that reference classes in the K multiplatform plugin, but as soon as I add this to my buildSrc 's build.gradle.kts :

dependencies {
    compileOnly("org.jetbrains.kotlin:kotlin-gradle-plugin:1.6.10") // Just innocently wanting to reference this
}

...Gradle gets 'very unhappy': this seems to mess with the class path and get me a mix of:

java.lang.IllegalArgumentException: org.gradle.api.internal.initialization.DefaultClassLoaderScope@d4aade2 must be locked before it can be used to compute a classpath!

...just generally, is referencing a plugin for its classes like this a no-no?

Seems the same as this issue

[Big Chungus]

Hah, plugins block is a special snowflake and not actually part of buildscript 😀

[Big Chungus]

So you can write extension functions for everything else, except the plugin block

[Javier]

I add there the plugin but using implementation instead of compileOnly, and that forces you to remove versions in all places except there

[Javier]

that message is appearing too when some gradle config exists plus on demand in gradle properties? but not sure if that is the problem here