Retry transient Maven Central failures
Enabled bounded Wagon HTTP retries, shortened pooled-connection reuse, and changed Maven wrapper download retries from fixed waits to exponential backoff.
apache/seatunnel · #12468
Build reliability
SeaTunnel's Maven wrapper and dependency resolution now tolerate short Maven Central rate limits, transient server errors, connection resets, and stale pooled connections.
Problem
Unrelated builds could fail when the uncommitted Maven wrapper jar received HTTP 429 responses beyond its prior 20-second retry window, or when Maven 3.8.4 encountered a transient 5xx response or exhausted its default I/O retries during dependency resolution.
Approach
Adds repository-wide Maven 3.8.4 Wagon settings for five retries, the standard 408/429/5xx strategy, and a 25-second connection TTL. The POSIX wrapper retains five download attempts but waits 5, 10, 20, and 40 seconds between failures.
Impact and scope
- Reduces false CI failures caused by brief Maven Central rate limits and service interruptions without retrying whole workflows.
- Applies dependency transport protection consistently to every Maven invocation through the standard .mvn/maven.config mechanism.
- Avoids reusing older pooled connections that are more likely to have been dropped while idle.
- Adds no delay on healthy downloads and keeps retries bounded during a sustained outage.
Validation
- Fault-injection tests on JDK 8 and JDK 11 recovered from two initial 503 responses, four connection resets, and a 30-second wrapper-jar 429 window; the old wrapper exhausted its attempts after about 21 seconds while the new schedule succeeded at 35 seconds.
- Maven 3.8.4 startup, property loading, and the CI code-style Maven build passed on both tested JDKs; all four current hosted checks pass.
- The change does not claim to recover truncated response bodies, sustained repository outages, or native Windows mvnw.cmd wrapper downloads; those remain documented limits.