Skip `extendsFrom(rootConfiguration)` for consumable-only configurations by FinlayRJW · Pull Request #1614 · palantir/gradle-consistent-versions

FinlayRJW · 2026-03-10T14:22:02Z

Before this PR

GCV applies conf.extendsFrom(rootConfiguration) to all configurations on every project. rootConfiguration contains a ProjectDependency on the root project. This creates a variant model cycle when two conditions are met on the root project:

A consumable-only configuration exists (e.g. created by a plugin like gradle-idea-language-injector)
That consumable config's outgoing artifacts are backed by a provider that resolves another configuration (e.g. compileClasspath)

Both configurations extend rootConfiguration (via GCV). On Gradle 9.4.0, gradle/gradle#36245 changed extendsFrom from eagerly storing parent configs in a Set<Configuration> to lazily storing them as Provider<Configuration>. When Gradle computes the root project's variant model, it now iterates consumable configs and evaluates their lazy extendsFrom chains. Following rootConfiguration → ProjectDependency(root) → re-enters variant model computation on root → cycle.

The real-world trigger is gradle-idea-language-injector, which creates a consumable config on the root project whose outgoing artifacts resolve compileClasspath to scan jars for annotations. See palantir/gradle-idea-language-injector#149 for a downstream workaround.

After this PR

Skips extendsFrom(rootConfiguration) for consumable-only configurations (canBeConsumed=true, canBeResolved=false). These are published variants that never resolve dependencies, so inheriting version constraints serves no purpose.

No behavior change for existing configs:

implementation, api, etc. — canBeConsumed=false → still gets extendsFrom
compileClasspath, runtimeClasspath — canBeResolved=true → still gets extendsFrom
apiElements, runtimeElements — already handled by JAVA_PUBLISHED_CONFIGURATION_NAMES

Possible downsides?

We are no longer extending from rootConfiguration for any consumable configuration - this could have some unseen side effect, but I don't think it should as we don't care about version constraints from the rootConfiguration on a consumable as they are never resolved

Testing

Consumable-only configurations (canBeConsumed=true, canBeResolved=false) are published variants that never resolve dependencies, so inheriting version constraints via extendsFrom is useless. It also creates a variant model cycle when rootConfiguration contains a ProjectDependency on the root project, which became a build failure in Gradle 9.4.0 due to gradle/gradle#36245.

changelog-app · 2026-03-10T14:22:07Z

Generate changelog in `changelog/@unreleased`

Type (Select exactly one)

Feature (Adding new functionality)
Improvement (Improving existing functionality)
Fix (Fixing an issue with existing functionality)
Break (Creating a new major version by breaking public APIs)
Deprecation (Removing functionality in a non-breaking way)
Migration (Automatically moving data/functionality to a new system)

Description

Skip extendsFrom(rootConfiguration) for consumable-only configurations

Check the box to generate changelog(s)

Generate changelog entry

FinlayRJW · 2026-03-10T16:15:13Z

src/test/java/com/palantir/gradle/versions/VersionsPropsPluginIntegrationTest.java

            allprojects {
                repositories {
-                    maven { url "file:///%s" }
+                    maven { url uri("%s") }


for some reason fails on gradle 9.4.0 without this?

Caused by: java.net.URISyntaxException: Illegal character in path at index 121: file:////Volumes/git/gradle-consistent-versions/build/gradle-plugin-testing/VersionsPropsPluginIntegrationTest/consumable only configuration on root project does not cause variant model cycle/9.4.0/build/mavenrepo/localMavenRepository at org.gradle.api.internal.file.FileNotationConverter.convert(FileNotationConverter.java:96)

what is said reason?

well gradle 8.14.3 -> gradle 9.4.0 gives:

file:////Volumes/git/gradle-consistent-versions/build/gradle-plugin-testing/VersionsPropsPluginIntegrationTest/consumable only configuration on root project does not cause variant model cycle/8.14.3/build/mavenrepo/localMavenRepository

vs

file:////Volumes/git/gradle-consistent-versions/build/gradle-plugin-testing/VersionsPropsPluginIntegrationTest/consumable only configuration on root project does not cause variant model cycle/9.4.0/build/mavenrepo/localMavenRepository

Whats weird is that the illegal character the error references to is a space which is present in both

maybe gradle 9 is stricter on having spaces in url strings?

ah yeah see: https://docs.gradle.org/9.4.0/userguide/upgrading_version_8.html#deprecated_invalid_url_decoding

~~idk, you tell me! can you go and verify that please?~~ thank you! what do you think that means for some of our excavators?

should be okay we have an explicit callout to use uri I added a bit ago:

// ALSO CORRECT - allprojects block when subprojects also need the repo rootProject.buildGradle().append(""" allprojects { repositories { maven { url uri("%s") } } } """, repo.path());

https://github.com/palantir/gradle-plugin-testing/blob/develop/docs/junit-migration-excavator-instructions.md

I would not say that it's explicit, it's just an example of adding repositories. If we're seeing this come up again, we should have an explicit callout along the line of:

don't use file:///... when in build.gradle test files, use uri("%s") instead as it is deprecated

one could argue, it's a separate concern as it's gradle 9 stuff, but I think it's far easier to nip it in the bud now whilst we're doing the migrations and it migrates to the proper thing, that's forward compatible, as we probably won't run a similar style AI assisted migration for gradle 9 stuffs.

sweet - see palantir/gradle-plugin-testing#416

changelog-app · 2026-03-11T09:29:05Z

✅ Successfully generated changelog entry!

Need to regenerate?

Simply interact with the changelog bot comment again to regenerate these entries.

📋Changelog Preview

💡 Improvements

Skip extendsFrom(rootConfiguration) for consumable-only configurations (#1614)

FinlayRJW · 2026-03-11T09:34:08Z

src/test/java/com/palantir/gradle/versions/VersionsPropsPluginIntegrationTest.java

    }

+    @Test
+    @AdditionallyRunWithGradle("9.4.0")


when all the tests are moved over we can start testing everything on 9.4.0

felixdesouza · 2026-03-11T16:47:50Z

src/main/java/com/palantir/gradle/versions/VersionsPropsPlugin.java

+        });
+    }
+
+    private static void setupConfigurationDependencies(


this is not a worthwhile change, please undo

have undone - but now require @SuppressWarnings("checkstyle:CyclomaticComplexity") I assume thats okay?

felixdesouza · 2026-03-11T16:58:05Z

src/main/java/com/palantir/gradle/versions/VersionsPropsPlugin.java

+        // Consumable-only configurations are published variants of a project — they never resolve
+        // dependencies, so version constraints from rootConfiguration are useless on them.
+        // Additionally, extending rootConfiguration here creates a variant model cycle on
+        // Gradle 9.4.0+. If a consumable config's outgoing artifacts provider resolves another config (e.g.
+        // compileClasspath) that also extends rootConfiguration.


when you say "published" what do you mean?

so version constraints from rootConfiguration are useless on them.

I'm not sure I buy this, can you explain your reasoning a bit more please? ~~What happens to configurations that are all three types? this happens in a lot of places.~~ Will they be broken when they get to 9.x? Probably, but I'm concerned about existing behaviour changing in subtle ways for 8.x. This is also for all consumable-only configurations, not just the root project as that was your initial problem.

If a consumable config's outgoing artifacts provider resolves another config (e.g. compileClasspath) that also extends rootConfiguration.

I can't parse this sentence, what are you trying to say here

when you say "published" what do you mean?

sorry, I mean consumable-only configurations are outgoing variants — they expose artifacts to consumers but never resolve dependencies themselves. Since they never resolve, version constraints inherited from rootConfiguration surely will have no effect on them

I can't parse this sentence, what are you trying to say here

Sorry I'm not 100% sure I fully understand but my best guess is extending rootConfiguration on a consumable-only config creates a variant model cycle on Gradle 9.4.0+ when that configurations outgoing artifacts resolve a configuration (e.g. compileClasspath) that also extends rootConfiguration. rootConfiguration ends up reachable from both sides — Gradle includes it in the variant model through the consumable config, and also needs to resolve it through compileClasspath. That circular dependency between variant discovery and resolution is what Gradle 9.4.0+ now rejects.

This is also for all consumable-only configurations

True I'll add a test to see if this can happen only within a subproject or if this is only an issue with root and tighten the check accordingly

I guess my qualm with this approach is that, underlying behaviour has changed in gradle 9.4, this change happens to avoid this new behaviour you don't want. However, what I don't get from this PR or its description is what the underlying problem is for this change to be deemed the correct fix. It just feels like because it solves the problem that it's then good to go, which I fundamentally disagree with.

FWIW, this might actually be the right fix, but it's hard to know that given what I'm seeing here, especially considering it may change behaviour for non gradle 9 use cases.

yeah thats fair - I'll give it some more thought I think I need to more fully understand how this has changed - will close this PR for now / convert to draft and try and figure out exactly what has changed and what the best fix is

FinlayRJW added autorelease merge when ready labels Mar 10, 2026

FinlayRJW added 4 commits March 10, 2026 15:07

minimise diff

1c78358

no need for link

3ab332b

minimise diff

c285c10

test

162bdfd

FinlayRJW mentioned this pull request Mar 10, 2026

Fix Gradle 9.4 variant model cycle without GCV workaround palantir/gradle-idea-language-injector#150

Closed

FinlayRJW commented Mar 10, 2026

View reviewed changes

FinlayRJW mentioned this pull request Mar 11, 2026

Fix Gradle 9.4.0 variant resolution failure with gradle-consistent-versions palantir/gradle-idea-language-injector#149

Closed

2 tasks

FinlayRJW requested a review from kelvinou01 March 11, 2026 09:29

FinlayRJW commented Mar 11, 2026

View reviewed changes

clearer message

8d8148c

felixdesouza reviewed Mar 11, 2026

View reviewed changes

FinlayRJW added 3 commits March 11, 2026 17:00

undo put in method

b8e9799

suppress CyclomaticComplexity

8daecce

improve comment

567d839

FinlayRJW marked this pull request as draft March 11, 2026 17:36

Conversation

FinlayRJW commented Mar 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Before this PR

After this PR

Possible downsides?

Testing

Uh oh!

changelog-app bot commented Mar 10, 2026 • edited by FinlayRJW Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Generate changelog in changelog/@unreleased

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

FinlayRJW Mar 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

felixdesouza Mar 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

changelog-app bot commented Mar 11, 2026

✅ Successfully generated changelog entry!

Need to regenerate?

📋Changelog Preview

💡 Improvements

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

felixdesouza Mar 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

FinlayRJW Mar 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

felixdesouza Mar 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

FinlayRJW commented Mar 10, 2026 •

edited

Loading

changelog-app bot commented Mar 10, 2026 •

edited by FinlayRJW

Loading

Generate changelog in `changelog/@unreleased`

FinlayRJW Mar 11, 2026 •

edited

Loading

felixdesouza Mar 11, 2026 •

edited

Loading

felixdesouza Mar 11, 2026 •

edited

Loading

FinlayRJW Mar 11, 2026 •

edited

Loading

felixdesouza Mar 11, 2026 •

edited

Loading