This message was deleted.

To do this, we wrap the Kotlin configuration blocks with:

public static void whenKotlinSupportPresent(Project p, Consumer<? super Project> action) {
        p.getPluginManager().withPlugin("org.jetbrains.kotlin.jvm", unused -> action.accept(p));
    }

I don't think this issue is relevant here

I created that issue because I had a plugins order issue and being unable to check if there is multiple plugins applied and not only one. My solution in my precompiled plugin was applying my plugin the last one which was not ideal…

in other words, this works:

plugins {
    alias libs.plugins.kotlin.jvm
    alias libs.plugins.kotlin.kapt
    alias libs.plugins.kotlin.allopen
    id 'io.micronaut.build.internal.oraclecloud-example'
}

and this doesn't:

plugins {
    id 'io.micronaut.build.internal.oraclecloud-example'
    alias libs.plugins.kotlin.jvm
    alias libs.plugins.kotlin.kapt
    alias libs.plugins.kotlin.allopen
}

but because of classloaders

Hm, very strange. I would have expected this to work. Maybe you found a bug?

I suspect this is caused by the the “root build” classloader thing. The subproject inherits the root loader. Your

io-micronaut...

is loaded there and operates in this context. The Kotlin stuff if loaded on top only in the subproject loader. That explains for me why it is not seen - which would be what I expect (although I think it’s a shitty behaviour, if I am correct).

probably something like this, yes. The

io.micronaut

plugin is loaded in

buildSrc

it works if I put all plugins on my script classpath (via

buildSrc

). Annoying.

That would confirm it. “buildSrc” is always in the root.

Ah, right.

I don’t know how to deal with this nicely in a plugin you share publicly. Other then recommending to users to make sure that all plugins involved are loaded (not necessarily applied) in the root. You could catch the ClassNotFound and print a corresponding advice as error. 😕

Maybe you could use the thread context class loader if it is set by Gradle. So that you have some "configure kotlin" class that you load from the thread context class loader in your plugin and that can then see the Kotlin classes?

That's my problem, I can't really know how the plugin is going to be applied 😕

loaded in the root.

iirc that wouldn't work if buildSrc is involved as it is the parent of the root project class loader

Death by a thousand classloaders

So you would need to create a new class loader that has the thread context class loader (if it is set properly) as parent class loader and then load your configure class from that new class loader, then it should properly see the classes without reflection

I won’t try to solve this in my plugin (if it was me). I would see to produce an error with good advice. Might probably be different depending on situation then. Things like:

If plugin applied in root -> 'apply id("other-plugin") false' in root
When used through buildSrc -> Add dependency 'implementation("other.plugin:coordinates")' to "buildSrc/build.gradle"

Yes, I can do something like that.

I would try to solve it, but I'm crazy 😄

This is a general Gradle plugin system design issue that should be addressed in Gradle itself

Maven makes it easier, since all plugins are loaded in isolation, and none can see the classes of another. With great powers come great responsibilities, said Hans.

Couldn't you make them separate plugins that you then apply in reaction to other plugins being applied, or was that also not possible? I mean to remember some problem there.

I have experienced a very similar problem with my plugin, and I even asked about it in this slack a long time ago. The only workaround that made sense was telling users to do this in their root build.gradle:

plugins {
  id 'kotlin' version 'whatever' apply false
}

because it is indeed a classloader issue where my plugin couldn't see the kotlin classes

when you apply

kotlin

without

jvm

,

multiplatform

and so on, suffix, it is like applying a general one?

it doesn't, I was being lazy

Note on this - AFAIK all Kotlin plugins are packaged in one Jar. Therefore, it does not matter which one you use in an “apply false” as Gradle loads the complete Jar onto he plugin classpath.

Not all kotlin plugins are in the same jar IIRC, all-open is another one

As I said above, even if you can get the class loader from the target project, for example if it is set as thread context class loader, that's just half the rent. If you load a class from your plugin through that class loader it wouldn't change anything, as class loaders first ask their parent class loader for the requested class and the highest class loader that finds it returns is, still only able to access classes from its own or higher class loaders. You need to have a separate class that does the configuration that is not part of your normal plugin class files (due to the parent-first delegation), then you need to create a new class loader that has the target project class loader as parent and adds the configuration class, then you load that configuration class from your new class loader. This class can then access the classes in the higher class loader and if it implements some interface that is actually available in your normal plugin classes, then you can also conveniently control that configuration class and go on without any reflection and without requiring the user to do something special. 🙂

I guess one of the ways to workaround the behavior is to use

reflection

API to configure target plugins. Even though it kind of defeats the reason to have

compileOnly

, it might be viable if you do not need to use

KotlinCompile

-like classes a lot.

Of course, the point here was to avoid reflection :-)