Using 2 gradle settings plugin

Help/Discuss
1

Hello,

I have a problem to use 2 gradle setting plugins at the same time in a test environment.

I have:

  1. a plugins jar that contains one settings plugin and multiple project plugins (applying AGP)
  2. an other ‘build’ project where I build an other settings plugin and another projects plugins.

Both of them are same plugins dependencies.

In my ‘build’ project 2, i use an GradleRunner build with a testing project that use also plugins from my bundled jars.

The testing project used by GradleRunner has this settings.gradle.kts file:

pluginManagement {
    plugins {
        id("my.setting.plugin.from1") version "X.Y.Z"
    }
}

plugins {
    id("my.setting.plugin.from1")
    id("my.setting.plugin.from2_under_test")
}

dslfrom1{
...
}
dslfrom2{
...
}

But when the testing project is loaded by the GradleRunner, i have the following error:

Extension of type ‘LibraryExtension’ does not exist. Currently registered extension types:
[…, LibraryExtension,… ]

Caused by: org.gradle.api.internal.plugins.PluginApplicationException: Failed to apply plugin class ‘project_plugin_from_1’.
at org.gradle.api.internal.plugins.DefaultPluginManager.doApply(DefaultPluginManager.java:173)
at org.gradle.api.internal.plugins.DefaultPluginManager.apply(DefaultPluginManager.java:151)
at X.X.X.X.apply(X.kt:21)

This problem occurs when a project-plugin from 1 is applied in a gradle module of my testing project.

I cannot reproduce the problem when I use my testing project directly (without gradle runner)
and use these 2 plugins bundles as local maven dependencies.

gradle version: 8.0.0

Thanks.

2

Sounds like a class loader problem.
The one registering LibraryExtension uses the class from one class loader,
while the one trying to get the extension uses the class from a different class loader.
As the classes are from different class loaders, they are not considered the same class and so the extension cannot be found.

I guess you use withPluginClassPath. Iirc, this can lead to such problems in more sophisticated situations like yours.
You should consider to instead publish the plugin to some file-based local repository (but not mavenLocal() which is broken by design), and then consume your plugin from that repository in your tests. This should hopefully resolve the class loader issue.