Track spring-retry version via BOM instead of pinning in consumer builds

[devondragon]

Background

PR #311 pinned spring-retry:2.0.12 in the README's required-deps list because Spring Boot's BOM doesn't always manage spring-retry for consumers. This works but has a downside: when Spring Boot eventually starts managing spring-retry in its BOM, consumers with the explicit pin may end up with a version drift or redundant constraint.

Goal

Publish a Gradle platform BOM (or at minimum document a BOM-based approach) so consumers can rely on dependency management rather than explicit version pins for spring-retry.

Options to consider

1. Publish a ds-spring-user-framework-bom Maven BOM / Gradle platform that declares managed dependency versions.
2. Use api (instead of compileOnly) for spring-retry so it's transitively available to consumers — though this conflicts with the library's "starters as compileOnly" philosophy.
3. Wait until Spring Boot's BOM manages spring-retry and remove the pin from the README at that point.

Priority

Low — the explicit version pin in the README is a working solution. This is a clean-up / DX improvement for a future release.

[devondragon]

Research findings

Spring Boot BOM status (confirmed)

Spring Boot 4.0 actively removed dependency management for spring-retry — this isn't a temporary gap. From the Spring Boot 4.0 Migration Guide:

With the portfolio moving from Spring Retry to new core features of Spring Framework, dependency management for Spring Retry has been removed. If your application still relies on Spring Retry, an explicit version is now required. Please consider moving your use of Spring Retry to Spring Framework.

Tracking issue: spring-boot#46309. The 4.0.6 Dependency Versions appendix no longer lists it.

Implication for Option 3 in this ticket: "Wait until Spring Boot's BOM manages spring-retry" is not going to happen — Boot is steering everyone to the new APIs instead.

spring-retry artifact status

2.0.12 (May 16, 2025) is the latest and likely final release. The project README declares it superseded by Spring Framework 7 and not accepting enhancements. So the explicit pin is effectively pinning to a frozen artifact — drift risk is low.

Spring Framework 7 core retry (the actual migration target)

Spring 7 ships retry in spring-core (org.springframework.core.retry) plus declarative annotations under org.springframework.resilience.annotation. Mapping vs. our current usage:

Current (spring-retry)	Spring Framework 7 core
@EnableRetry	@EnableResilientMethods
@Retryable (retry.annotation)	@Retryable (resilience.annotation)
maxAttempts	removed → use maxRetries
@Recover	Not yet ported — see spring-framework#35685
RetryTemplate	RetryTemplate (new API in spring-core)

The @Recover gap matters for us: MailService has two @Recover methods (recoverSimpleMailMessage, recoverTemplatedMessage) that log + suppress instead of re-throwing after exhaustion. Migration is blocked until either Spring Framework adds an equivalent or we rewrite the recovery as a try/catch / RetryListener.

Multi-Boot constraint

The library targets Boot 4.0 (Java 21+) and Boot 3.5 (Java 17+). Any Spring 7 core retry migration would be Boot 4 / Spring 7 only — the 3.5 branch must keep using spring-retry. That makes the migration non-trivial unless we drop Boot 3.5 support first.

Re-rank of the three options in the issue

1. Publish a Gradle platform BOM — just moves the pin behind a BOM; doesn't change the fact that consumers need an explicit version since Boot won't manage it again. Overkill for the value delivered.
2. Switch to api — violates the compileOnly philosophy. Skip.
3. Wait for Boot's BOM — won't happen.

The real cleanup target is migrating MailService to Spring 7 core retry, gated on:

• Resolution of @Recover story (spring-framework#35685), or a rewrite of the recovery logic
• Decision on Boot 3.5 support timeline

Decision

Keeping the README pin in place — it's the correct current solution. Repurposing this ticket from "investigate BOM" to "investigate Spring Framework 7 core retry migration" for a future release. No action needed until the @Recover replacement story settles and/or we drop Boot 3.5 support.