From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

Is there an attribute one can set on an outgoing variant to indicate a library should only be added to runtime scope if Gradle version is within a certain range?

So instead of `attribute(TargetJvmVersion.TARGET_JVM_VERSION_ATTRIBUTE, 17)` something like `attribute(TARGET_GRADLE_VERSION_ATTRIBUTE, 7)`

Maybe this? GradlePluginApiVersion.GRADLE_PLUGIN_API_VERSION_ATTRIBUTE

<https://docs.gradle.org/current/javadoc/org/gradle/api/attributes/plugin/GradlePluginApiVersion.html>

It's used by the Kotlin plugin <https://github.com/JetBrains/kotlin/blob/0f5c8a7e298863f23360be4e24ce16b8aba4f9d4/repo/gradle-build-conventions/buildsrc-compat/src/main/kotlin/GradleCommon.kt#L531|here>

Close, but not quite. I need something that can do `[7.0,8.0)`

I think that only indicates the minimum Gradle version, whereas I really need the opposite.

How do you want to consume the library? With your own Gradle plugin/resolvable configuration? In this case you could set up a AttributeCompatibilityRule :thinking_face: 

Besides an own compatibility rule, you would have one variant without version for <=7 (if that applies), one variant with version 7 for 7..<8 and one variant with version 8 for 8+. That's the standard way to have a variant for 7..<8.

The nearer 8-rule will win over the 7 rule. 
If you only want to support 7..&lt;8 and fail resolution for 8+, make the variant broken by referencing a missing artifact. If you want it to be a noop for 8+, just have a noop plugin in that variant

<@U04BSD8EZ25> I am trying to solve this issue <https://gitlab.com/ysb33rOrg/gradle/simplified-jruby-gradle-plugin/-/issues/20>

I want to get rid of the groovy-nio dependency from the classpath. If I remove it, Gradle tests &lt; 8.0 fail. Thus the immediate solution I looked at was to only have the dependency if the plugin is used with Gradle 7.

(W_hy it happens I don't know, which might be the real problem to solve_).

Well, well, well. Looks like I actually found the root-cause, so I don't need to do a variant.

However, <@URQ797WRW> do you have an OSS example of what you suggested? I am still curious in case I need to do it in future.

As <@UMCNY0BFH> said, for example KGP.
It has a variants with plugin api version set to 8.0, 8.1, 8.2, 8.5, and some others, but just looking at those four, ignoring the others, those variants are 8.0..<8.1, 8.1..<8.2, 8.2..<8.5, 8.5+.

The exact match chooses an exact match, 
otherwise the compatibility rule chooses all that are &lt;= the used Gradle version and then the disambiguation rule chooses the highest version of those. 
Gradle version &lt;7 do not request the attribute, so will pick the variant without that extra attribute.
Gradle versions not supporting GMM will pick the default variant from the POM.