I have a library that produces two variants - one for JDK8 and one for JDK17+. The latter variant has one more transitive RUNTIME dependency. If I write a plugin that consumes this library and I compile it against JDK17 it does select the correct variant (and also for JDK8). Also if you write a build.gradle which uses a plugin that uses the above library it will select the correct variant. But what I want to do in my plugin that I am writing is compile main against JDK8, then compile and run Testkit-based tests against JDK17. The problem is that the runtimeClasspath already selected the JDK8 variant and that is what appears on the plugin manifest. And the reason this is important is that I might want to test Gradle 8 running JDK8, but test against Gradle 9 running JDK17. That additional RUNTIME dependency has optimisations for Gradle9, but they don't get loaded in the tests due to the manifest problem and thus some bugs be missed. I have not really found a nice solution to this, so I would be interested in what people would suggest. (P.S. Please do not comment on the JDK versions used, they are for illustrative purposes only).

What do you mean with "plugin manifest"? The

withPluginClasspath()

metadata file?

Yes, that one.

I'd say don't use it. From the top of my head I'd say you have two options. Either publish to some local repo and consume in the tests from there, then the SUT build can select the proper variant. Or use

withClasspath()

where you give whether a Java 8 configured resolvable configuration or a Java 17 configured one into. (Or an artifact view with variant reselection should probably also be enough and more appropriate)

withPluginClasspath()

should be deprecated….

Why should it be deprecated? It is quite handy for simple plugins / cases.

Always the same thing. You believe it's handy. Then you grow your app/plugin and you shoot yourself in the foot.

Well, that's a matter of PoV and I fully disagree. That would mean you need to remove a lot of things that are convenient and make Gradle unusable. For example the property delegates much increased usability but were removed. But you would also need to for example remove the possibility to do

configurations.implementation

as you can also do

configurations.named("implementation")

to do the same. And many other things that are handy.

@Martin I don't agree. I think they are both clear in what they do.

Sets the plugin classpath based on the Gradle plugin development plugin conventions

vs

Sets the injected plugin classpath for the build

.

Agree to disagree! 🤝

@Vampire Do you think it is normal for an ArtifactView to fail with configuration cache when artifact reselection is used?

No,

lenient = true

is practically never what you want. It ignores almost each and every exception that could happen, including download exceptions and so on. It is usually only useful for things it really doesn't matter if it is not present like requesting sources.

Yes, it fails because it could not resolve any of the dependencies in the configuration. For example

Configuration cache state could not be cached: field `classpath` of task `:gradleTestClasspathManifest` of type `org.ysb33r.gradle.gradletest.ClasspathManifest`: error writing value of type 'org.gradle.api.internal.file.collections.DefaultConfigurableFileCollection'
> Could not resolve all files for configuration ':gradleTestCustomManifest'.
   > Unable to find a variant of org.spockframework:spock-core:2.4-groovy-3.0 providing the requested capability org.spockframework:spock-core:2.4-groovy-3.0:

Even adding all of the configurations attributes into view does not solve the issue