JavaSourceSetUpdater in dependency recipes breaks rewrite-spring CI

[Jenson3210]

Summary

Since rewrite 8.79.2, the scheduled CI in openrewrite/rewrite-spring has 5 consistently failing tests. The failures started on April 11, immediately after the 8.79.2 release (April 10, 23:25 UTC) was picked up by the latest.integration resolution. The last passing scheduled run was April 10 at 18:40 UTC.

• PR Prevent marker-only changes from producing phantom diffs #7358 (shipped in 8.79.3) fixed the flywayStarterOmitsVersionWhenManagedByParent test but these 5 failures persist.

Root Cause

• PR Expand star imports in ChangePackage and related recipes when they would create ambiguity #7202 ("Expand star imports in ChangePackage and related recipes") added JavaSourceSetUpdater integration to AddDependency, ChangeDependency, RemoveDependency, and UpgradeDependencyVersion for both Maven and Gradle. This causes:

1. Cycle inflation: Marker updates in cycle 1 trigger unnecessary cycle 2
2. Silent recipe failures: Dependency recipes fail to apply changes (ChangeDependency doesn't rename, AddDependency doesn't add)

Failing Tests

Test	Error
Boot3UpgradeTest.xmlBindMissing	"Expected recipe to complete in 1 cycle, but took 2 cycles"
RenameDeprecatedStartersManagedVersionsTest.renameStarterWithoutVersionWhenDepMgmtPluginPresent	Starter not renamed — actual output still has spring-boot-starter-web instead of spring-boot-starter-webmvc
RenameDeprecatedStartersManagedVersionsTest.renameStarterWithVersionWhenDepMgmtPluginAbsent	Same
MigrateToModularStartersTest.addFlywayStarterWhenDependencyPresent [flyway-database-postgresql]	"Expecting actual not to be null" — recipe produced no changes
MigrateToModularStartersTest.addFlywayStarterWhenDependencyPresent [flyway-mysql]	Same

Failing CI Runs

• April 13 scheduled: https://github.com/openrewrite/rewrite-spring/actions/runs/24361499711
• April 12 scheduled: https://github.com/openrewrite/rewrite-spring/actions/runs/24313556406
• April 11 scheduled: https://github.com/openrewrite/rewrite-spring/actions/runs/24288866962
• April 14 PR (with 8.79.3): https://github.com/openrewrite/rewrite-spring/actions/runs/24393073914 (same 5 failures)

Last passing scheduled run (April 10, pre-8.79.2): https://github.com/openrewrite/rewrite-spring/actions/runs/24258414542

Analysis

• The JavaSourceSetUpdater changes in PR Expand star imports in ChangePackage and related recipes when they would create ambiguity #7202 modified the Gradle dependency recipes in three ways:

1. Scanner phase: Records modulesWithOldDependency and moduleRepositories by scanning GradleProject configurations
2. isAcceptable: Now also accepts JavaSourceFile instances so the editing visitor processes Java source files
3. visit: For Java source files, calls updateJavaSourceSet() which downloads JARs and updates type information

The RenameDeprecatedStartersManagedVersionsTest failures are particularly telling: the UpgradeSpringBoot_4_0 recipe chain successfully upgrades the Spring Boot plugin version (from 3.4.1 to 4.0.5), but the subsequent ChangeDependency sub-recipe for renaming spring-boot-starter-web → spring-boot-starter-webmvc silently doesn't fire. This suggests the JavaSourceSetUpdater integration in either UpgradeDependencyVersion or ChangeDependency is interfering with the recipe chain execution.

Affected Files

• rewrite-gradle/src/main/java/org/openrewrite/gradle/ChangeDependency.java
• rewrite-gradle/src/main/java/org/openrewrite/gradle/AddDependency.java
• rewrite-gradle/src/main/java/org/openrewrite/gradle/UpgradeDependencyVersion.java
• rewrite-maven/src/main/java/org/openrewrite/maven/utilities/JavaSourceSetUpdater.java
• rewrite-java/src/main/java/org/openrewrite/java/marker/JavaSourceSet.java

[Jenson3210]

Root Cause Analysis Update — Precise Bug Identified

Bug 1: ChangeDependency routing bug (DEFINITIVE — explains RenameDeprecatedStarters failures)

In rewrite-gradle/src/main/java/org/openrewrite/gradle/ChangeDependency.java, the outer visitor's visit() method (lines 549-553) has a critical routing error:

// For Java source files, update JavaSourceSet marker
if (hasModulesWithOldDep && tree instanceof JavaSourceFile) {
    return updateJavaSourceSet((SourceFile) tree, ctx);   // ← SHORT-CIRCUITS HERE
}
return gradleVisitor.visit(tree, ctx);                    // ← NEVER REACHED for .gradle files

The problem: G.CompilationUnit implements JavaSourceFile (see rewrite-groovy/.../G.java:74). When hasModulesWithOldDep is true, Gradle build files (.gradle) match the instanceof JavaSourceFile check and are routed to updateJavaSourceSet() instead of gradleVisitor.visit() — the visitor that actually renames dependencies. The dependency renaming is completely skipped.

When hasModulesWithOldDep becomes true: The scanner (lines 206-219) finds the old dependency in GradleProject.getConfigurations() and records it in acc.modulesWithOldDependency (keyed by JavaProject). If the build.gradle file has both GradleProject and JavaProject markers (added by withToolingApi()), this map is populated, setting hasModulesWithOldDep = true.

Comparison with other recipes that don't have this bug:

Recipe	Routing logic	Bug?
ChangeDependency	Checks JavaSourceFile before gradleVisitor	YES
AddDependency	Checks gradleVisitor.isAcceptable() first, then JavaSourceFile	No
RemoveDependency	Checks gradleVisitor.isAcceptable() first, then JavaSourceFile	No
UpgradeDependencyVersion	Explicitly excludes G.CompilationUnit and K.CompilationUnit	No

Suggested fix (matching what UpgradeDependencyVersion does):

if (hasModulesWithOldDep && tree instanceof JavaSourceFile
        && !(tree instanceof G.CompilationUnit) && !(tree instanceof K.CompilationUnit)) {
    return updateJavaSourceSet((SourceFile) tree, ctx);
}
return gradleVisitor.visit(tree, ctx);

Or alternatively (matching what AddDependency / RemoveDependency do):

SourceFile sf = (SourceFile) tree;
if (gradleVisitor.isAcceptable(sf, ctx)) {
    return gradleVisitor.visit(tree, ctx);
}
if (hasModulesWithOldDep && sf instanceof JavaSourceFile) {
    return updateJavaSourceSet(sf, ctx);
}
return tree;

This also needs to be fixed in the isAcceptable() method (line 519), which currently accepts .gradle files twice — once at line 514-516 (correctly) and again at line 519 via the JavaSourceFile check.

Bug 2: AddDependency new early-return path (possible — MigrateToModularStarters)

PR #7202 added new fields to AddDependency.Scanned: resolvedVersion, repositories, versionResolutionFailure. The getVisitor() method (line 315) now has:

if (acc.configurationsByProject.isEmpty() || acc.resolvedVersion == null) {

Before PR #7202, this was just:

if (acc.configurationsByProject.isEmpty()) { ... }
// (and the method directly returned the visitor)

The added || acc.resolvedVersion == null creates a new path: if version resolution fails or doesn't happen during scanning (e.g., no source file with GradleProject marker is encountered before the check), the method returns the gradleVisitor directly. While this SHOULD still work (it's the pre-PR behavior), if version resolution throws a MavenDownloadingException, the error-wrapping visitor is returned instead, which adds Markup.warn to any changes.

I haven't been able to pinpoint the exact mechanism for the MigrateToModularStarters failures. This needs local reproduction with debug logging.

Bug 3: Cycle issue (Boot3UpgradeTest.xmlBindMissing)

The Maven ChangeDependencyGroupIdAndArtifactId and UpgradeDependencyVersion now update JavaSourceSet markers on Java source files. PR #7358 partially addressed phantom diffs but the cycle detection in LargeSourceSetCheckingExpectedCycles still fires for this specific test. The recipe chain in UpgradeSpringBoot_3_0 includes many dependency-modifying recipes that each update markers, and the cumulative marker changes appear to cause detectable modifications across cycles.

---

Summary

• RenameDeprecatedStarters (2 tests): Caused by Bug 1 — definitive, with a clear fix
• MigrateToModularStarters (2 tests): Likely related to Bug 2 or interaction effects; needs reproduction
• Boot3UpgradeTest (1 test): Bug 3 — marker updates causing extra cycles; PR Prevent marker-only changes from producing phantom diffs #7358 was insufficient