[timtebeek]

Summary

• UpdatePrometheusPushgateway and MigrateCloudSleuthToMicrometerTracing swap to artifacts whose version history differs from the original's, without a newVersion.
• ChangeDependency therefore kept the old version literal, which resulted in versions that don't exist or a mismatched Spring Boot version.
• Set an explicit version on each of these swaps.

Problem

Recipe	Swap	Result with an explicit old version
UpdatePrometheusPushgateway	simpleclient_pushgateway (0.x) → prometheus-metrics-exporter-pushgateway (1.3.0+)	prometheus-metrics-exporter-pushgateway:0.16.0 → Unable to download POM ... HTTP 404
MigrateCloudSleuthToMicrometerTracing	spring-cloud-sleuth-otel-autoconfigure (1.1.x) → spring-boot-actuator-autoconfigure	spring-boot-actuator-autoconfigure:1.1.4 → HTTP 404
MigrateCloudSleuthToMicrometerTracing	spring-cloud-sleuth-autoconfigure (3.1.x) → spring-boot-actuator-autoconfigure	resolves, but to Boot 3.1.11 instead of 3.0

The recipe writes the unresolvable version and leaves only a warning comment in the POM, so tests that check just the artifact ID still pass.

Solution

• UpdatePrometheusPushgateway: newVersion: 1.3.x, matching the prometheus-client.version that Spring Boot 3.5 manages (1.3.6–1.3.10).
• Both Sleuth autoconfigure swaps: newVersion: 3.0.x, consistent with the 3.0.x the same recipe already uses for spring-boot-starter-actuator.

When the version is managed by the Spring Boot BOM, the dependency stays versionless; a new test covers this.

These were found in a catalog-wide check of dependency-swap steps against Maven Central metadata.

Test plan

• New UpdatePrometheusPushgatewayTest: the explicit-version test fails before the change and passes after; the managed-version test passes either way
• Two new MigrateCloudSleuthToMicrometerTracingTest cases fail before the change and pass after
• UpgradeSpringBoot_3_5Test, cloud2022.MigrateProjectTest and the other Sleuth test classes pass