#1687 ("Lift AWS versions 4.1.x") bumped awssdk-v2.version from 2.47.4 to 2.54.3 on the 4.1.x branch, and it shipped in 4.1.1 (which closed #1686). The change doesn't seem to have been forward-ported to main, so 4.2.0 (#1707) was released with the older SDK:
| Release |
awssdk-v2.version in spring-cloud-aws-dependencies |
| 4.1.0 |
2.47.4 |
| 4.1.1 |
2.54.3 |
| 4.2.0 |
2.47.4 |
main (4.3.0-SNAPSHOT) is also still on 2.47.4.
As a result, upgrading from 4.1.1 to 4.2.0 downgrades the AWS SDK and brings back the problem from #1686. When anything else on the classpath pulls a newer sdk-core, service-client jars resolved at 2.47.4 fail with AbstractMethodError. We hit the same thing with AWS SDK 2.53+ (2.53.0 removed ServiceMetadata from the request path), where secretsmanager:2.47.4 against sdk-core:2.53.1 fails at runtime.
Could #1687 be forward-ported to main, ideally for a 4.2.1?
#1687 ("Lift AWS versions 4.1.x") bumped
awssdk-v2.versionfrom 2.47.4 to 2.54.3 on the4.1.xbranch, and it shipped in 4.1.1 (which closed #1686). The change doesn't seem to have been forward-ported tomain, so 4.2.0 (#1707) was released with the older SDK:awssdk-v2.versioninspring-cloud-aws-dependenciesmain(4.3.0-SNAPSHOT) is also still on 2.47.4.As a result, upgrading from 4.1.1 to 4.2.0 downgrades the AWS SDK and brings back the problem from #1686. When anything else on the classpath pulls a newer
sdk-core, service-client jars resolved at 2.47.4 fail withAbstractMethodError. We hit the same thing with AWS SDK 2.53+ (2.53.0 removedServiceMetadatafrom the request path), wheresecretsmanager:2.47.4againstsdk-core:2.53.1fails at runtime.Could #1687 be forward-ported to
main, ideally for a 4.2.1?