[Spring Boot 4] Integrate Spring Data 4 migration and honour datastore migration blockers

[Kyran121]

Related work

• Introduce UpgradeSpringData_4_0 as an incrementally extensible composite recipe #1080 introduced UpgradeSpringData_4_0.
• [Tracking] Add Spring Data MongoDB 5.0 migration support #1081 tracks Spring Data MongoDB 5 migration support.
• [Spring Data MongoDB 5.0] Migrate removed MongoDB JMX support without breaking compilation #1085 defines how removed Spring Data MongoDB JMX usage should be migrated while preserving compilability.

Problem

UpgradeSpringBoot_4_0 updates the Spring Boot parent/BOM/dependencies to 4.0, which selects the Spring Data 2025.1 release train. The current Boot 4 composite does not run UpgradeSpringData_4_0 before those dependency-management changes.

That leaves a sequencing gap: datastore-specific source migrations may need the source platform's type attribution and may identify source that requires manual remediation before the target datastore version is selected. A Boot parent/BOM change can otherwise bypass that focused migration decision. #1085 provides the first concrete case because Spring Data MongoDB 5 removes JMX APIs that existing source may still reference.

Proposed solution

• Run UpgradeSpringData_4_0 during the pre-Boot-4 migration phase, before Boot 4 dependency-management changes select the target Spring Data train.
• Reuse explicit migration-readiness/blocker information from focused datastore recipes instead of duplicating datastore analysis in Boot-specific code.
• Use [Spring Data MongoDB 5.0] Migrate removed MongoDB JMX support without breaking compilation #1085 as the first integration: if its MongoDB JMX analysis finds unsupported source that still requires manual migration, keep the enclosing Boot platform change aligned with that result.
• Allow safe preparatory source migrations to run first.
• Preserve focused diagnostics at the exact source sites requiring manual work.
• After those sites are remediated, rerunning the recipe should continue the remaining Boot 4 migration idempotently.

Shared parent / BOM scope

Module-level analysis is not sufficient when a shared Maven parent, imported BOM, Gradle platform, or plugin controls versions for several modules.

For shared ownership, evaluate migration readiness across the modules affected by that shared platform change. A shared Boot 4 update should only proceed when the affected ownership scope is ready for the target datastore versions. Independently versioned modules may proceed separately where ownership can be established reliably.

Proposed implementation shape

The following is intended as orchestration guidance, not a prescription of exact recipe classes or internal APIs.

Prepare source for Boot 4
        |
        +-- run Spring Data 4 migration support
        +-- apply safe datastore-specific source changes
        `-- collect migration blockers

                     |
                     v
              report blockers

                     |
                     v
          Spring Boot 4 platform transition
                     |
              only when safe

A likely shape is to:

• run datastore/source migrations before Boot 4 parent/BOM/dependency changes remove source-platform type attribution;
• reuse blocker/readiness information produced by focused datastore recipes rather than re-analysing datastore semantics in the Boot recipe;
• keep diagnostics independent of the final platform-transition guard so users still see the exact manual remediation sites when the Boot 4 transition is withheld;
• evaluate readiness at the ownership scope of the version change: module scope for independently versioned modules, and shared parent/BOM/platform scope where one change affects multiple modules;
• permit safe preparatory migrations to remain applied even when the final Boot 4 transition is blocked;
• allow a subsequent rerun to continue the remaining migration once blockers have been remediated.

#1085 should be the first concrete consumer of this pattern, but the orchestration should remain general enough for future datastore or platform migration blockers.

The exact mechanism for aggregating readiness, associating modules with dependency-management ownership, structuring declarative preconditions, or implementing project-aware scanning is intentionally left to the implementor.

Acceptance criteria

• UpgradeSpringBoot_4_0 runs UpgradeSpringData_4_0 before Boot 4 dependency-management changes that select Spring Data 2025.1.
• Datastore-specific analysis is reused rather than duplicated in the Boot recipe.
• [Spring Data MongoDB 5.0] Migrate removed MongoDB JMX support without breaking compilation #1085 migration readiness is respected when Boot 4 would indirectly select Spring Data MongoDB 5.
• Safe preparatory migrations can run before the Boot platform change.
• Shared-parent/BOM multi-module scenarios are evaluated across the affected ownership scope.
• Independently versioned modules can proceed independently where ownership is clear.
• After manual remediation, rerunning continues the remaining migration without duplicating prior changes.
• Existing Boot 4 migrations without datastore blockers continue normally.
• Tests cover single-module, shared-parent multi-module, independently versioned, blocked/readiness, rerun, and idempotent scenarios.

Out of scope

• Reimplementing MongoDB JMX analysis in the Boot recipe.
• Treating every diagnostic as a migration blocker.
• Deleting application-specific code solely to make the target platform compile.
• Solving every future Boot 4 migration blocker in this issue.