Restore dependency management for child modules of a local parent

[timtebeek]

Summary

• ChangeParentPom / UpgradeParentVersion now restore dropped dependency management in a local parent on behalf of the child modules that declare those dependencies, not just the parent's own dependencies.

Problem

When upgrading a parent (e.g. Spring Boot 2.7 → 3.0), the recipe restores dependency management for dependencies that the new parent no longer manages. It only looked at dependencies declared by the pom whose <parent> was being changed.

In a multi-module project where a local parent declares the upgraded parent (e.g. spring-boot-starter-parent) and the child modules declare the affected dependencies without an explicit version, nothing was restored — the local parent declares none of those dependencies itself, and the child modules' direct parent (the local parent) isn't what's being changed. The result was unresolvable dependencies and module resolution errors after the upgrade.

• Reported in moderneinc/customer-requests#2589.

Solution

In addition to the pom being changed, also inspect descendant modules that inherit from it (gathered from the scanning accumulator's resolution markers). Dependency management that the new parent drops is restored in the local parent on behalf of any descendant module that declares the dependency without an explicit version. Restored entries are de-duplicated by groupId:artifactId. Single-module behavior is unchanged.

Note for reviewers

The added test asserts the management is restored in the local parent (the fix). The child module additionally renders a transient No version provided for direct dependency ... warning marker: within a single run the child's in-memory model isn't re-resolved against the local parent's newly-added management (cross-module model propagation here is order-dependent, and only the parent version is propagated through the resolution markers today). This marker is not written to the pom file and is present on main for this scenario as well; it clears on the next parse, so the resulting build resolves correctly. Making that propagation order-independent would be a larger, separate change to the multi-module marker machinery.

Test plan

• Existing ChangeParentPomTest / UpgradeParentVersionTest pass

• New ChangeParentPomTest.RetainVersions#bringsDownRemovedManagedVersionDeclaredInChildModuleOfLocalParent fails on main, passes with the fix

• Fixes moderneinc/customer-requests#2589