ChangeDependency skips dependencies whose new coordinates don't resolve

[steve-aom-elliott]

Summary

When ChangeDependency uses glob patterns (e.g. org.hibernate:hibernate-* → org.hibernate.orm), it was incorrectly changing the groupId of artifacts that don't exist under the new group — like hibernate-validator, which belongs to org.hibernate.validator not org.hibernate.orm. It also updated the shared version variable, breaking the unchanged dependency.

All warning suppression and silent-skip behavior is gated on glob pattern usage (* or ? in oldGroupId/oldArtifactId). For non-glob patterns, the original e.warn() behavior is preserved so users still see resolution failures from misconfigured environments.

Gradle ChangeDependency

Core change: track per-artifact resolution failures when using globs. The scanner now records which specific GroupArtifact coordinates fail version resolution in failedResolutions (only when the pattern contains wildcards). This feeds into two places:

1. canUpdateVariable — returns false when any matching artifact sharing a version variable failed resolution. This prevents the shared variable from being updated, and routes deps through the !canUpdateVariable path where successful deps get hardcoded versions and failed deps are skipped.

2. updateDependency — checks failedResolutions at the top and returns the original tree for deps whose new coordinates don't exist.

Additional fix: Scanner uses putIfAbsent for exceptions (glob only) so a successful resolution from one artifact isn't overwritten by a failure from another sharing the same variable.

Result: Given hibernateVersion = '5.6.15.Final' shared by hibernate-core and hibernate-validator:

• hibernate-core → org.hibernate.orm:hibernate-core:6.0.2.Final (hardcoded, detached from variable)
• hibernate-validator → unchanged (org.hibernate:hibernate-validator:${hibernateVersion})
• hibernateVersion → stays at 5.6.15.Final

Maven ChangeDependencyGroupIdAndArtifactId

On resolution failure: returns tag unchanged when glob patterns are in use (artifact doesn't exist under new coordinates). Preserves e.warn(tag) for non-glob patterns.

Maven ChangeManagedDependencyGroupIdAndArtifactId

On resolution failure: returns tag unchanged when glob patterns are in use. Preserves e.warn(t) for non-glob patterns. (Previously returned e.warn(t) which kept the modified groupId/artifactId AND added a warning — the original tag is now returned for the glob case.)

Test plan

• New test doesNotChangeGroupIdWhenNewCoordinatesDontResolve: Gradle build with hibernateVersion property shared by hibernate-core and hibernate-validator, glob ChangeDependency hardcodes hibernate-core's version, leaves hibernate-validator and the shared property untouched
• All existing ChangeDependencyTest tests pass
• All existing ChangeDependencyGroupIdAndArtifactIdTest tests pass
• All existing ChangeManagedDependencyGroupIdAndArtifactIdTest tests pass

[timtebeek]

I have a small worry here swallowing exceptions when we're running in a new environment that doesn't have credentials or repository access set up correctly. I can understand it if we want to suppress warnings when it's part of wildcard upgrade flow, but might it make sense to make that conditional / explicit here? To only suppress if wildcards are in play? Because if that's not the case as a user I'd want to see the failure. Or what's your view on this?

Same applies elsewhere above.

[steve-aom-elliott]

You're correct. I had actually discussed this and asked about it, but it seems to have skipped doing it and I missed it in the last look through. Will get another adjustment to that pushed shortly

[steve-aom-elliott]

Good call Tim — pushed a commit that gates all warning suppression on whether the pattern contains wildcards (* or ?). For non-glob patterns, the original e.warn() behavior is preserved so users still see resolution failures from misconfigured environments.

[timtebeek]

Thanks for the quick turnaround; should make the downstream recipes easier to write and reason about.