Is it an unexpected use case to write extension-fu...
# gradle
d
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 🧵 👉
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
:
Copy code
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:
Copy code
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
b
Hah, plugins block is a special snowflake and not actually part of buildscript 😀
So you can write extension functions for everything else, except the plugin block
j
I add there the plugin but using implementation instead of compileOnly, and that forces you to remove versions in all places except there
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