Spring Cloud BOM Not Updating During Independent Spring Cloud Upgrades

Products

• VMware Tanzu Spring Runtime

Issue/Introduction

When executing an automated upgrade plan, spring-cloud-commons (or other individual Spring Cloud dependencies) may be upgraded to a newer version without a corresponding update to the Spring Cloud BOM (spring-cloud-dependencies). This results in a fractured dependency tree where specific Spring Cloud modules are out of sync with the overall release train.

Symptoms

• The upgrade plan runs successfully, but the application fails to compile or start.
• You encounter ClassNotFoundException or NoSuchMethodError during application startup.
• Inspecting your pom.xml or build.gradle shows a newer version of spring-cloud-commons explicitly defined, but the dependencyManagement section still points to an older Spring Cloud release train.

Environment

Spring Application Advisor up to 1.5.5

Cause

The root cause is tight coupling within the upgrade automation recipes. Currently, the automation logic that dictates the Spring Cloud BOM upgrade is nested entirely within the Spring Boot upgrade process.
If the advisor decides to upgrade a Spring Cloud dependency in a step that does not include a Spring Boot upgrade (for example, stepping spring-cloud-commons from 3.0.x to 3.1.x before touching Boot), the condition to update the BOM is never triggered. The tool forcefully overrides the version of the single dependency while ignoring the overarching BOM.
Impact
By bypassing the Spring Cloud BOM, the dependency management system is broken. Mixing Spring Cloud library versions across different release trains leads to incompatible transitive dependencies and runtime crashes.

Resolution

Workaround / Resolution

Until the underlying automation recipes are refactored to decouple the Spring Cloud BOM upgrade from the Spring Boot upgrade, you must stop using Spring Cloud SBOMs: Instead rely on specific versions of Spring Cloud artifacts.