I’m developer of a Gradle plugin and currently upgrading to Gradle 7. The upgrade itself works without problems.
Now I tried the upgraded plugin in a build script using Gradle Wrapper 6.8.3, which fails with some strange errors (something with Gradle’s WorkAction/Worker api, the plugin uses internally). Upgrading the build to Gradle Wrapper 7.0 fixes the issue.
Maybe this is a bug - though I ask myself how I would communicate to the users of the plugin that they might have to upgrade to Gradle 7 when upgrading the plugin. I could even publish different releases of the same plugin, for each supported Gradle version.
What if I could declare the supported Gradle versions in the pluginBundle config when publishing the plugin so that Gradle could the select the “best” matching plugin variant? Would that be possible?
What you are after / suggesting is this which was introduced with Gradle 7: Implementing Gradle plugins
So starting with Gradle 7 you can do exactly that, provide different variants for different Gradle versions.
For older Gradle versions you need the classical “if version then use class X otherwise use class Y” or “if class A is available then use class X otherwise use class Y” tactics.
On the consumer side with Gradle 7 it doesn’t select that variant, though. I expected Gradle 7 to implicitly match on the "org.gradle.plugin.api-version": "7.0" attribute, but it selects the non-gradle7 default variant.
Can you tell how I can see which variant Gradle selected, and if I have to configure anything on the consumer side?
On the consumer side it should not be necessary to configure anything, that’s the point.
Unfortunately I’m not sure how to check that with build script dependencies.
With normal dependencies, dependencyInsight task would give you the information about which varinat was selected and which attributes were only chosen a compatible version instead of the requested version.
And I didn’t try this functionality yet, I just have read about it.
Do you maybe have an MCVE?