《Spring Integration for AWS》一直是一个独立的 Spring Integration 扩展项目，拥有自己的计划和发布周期。从依赖管理角度来看，使用这个单一的 jar 库总是增加了复杂性。它不仅依赖于 Spring Integration 模块（如 HTTP 和 File），还直接依赖于Spring Cloud AWS，当然也依赖于 AWS SDK。大多数依赖都是optional的，因为该项目为不同的 AWS 集成（如 S3、SQS、DynamoDB、SNS 和 Kinesis）提供了通道适配器和组件。因此，目标项目不仅会在 Spring Boot 和 Spring Cloud 版本匹配方面遇到困难，还会受到原生 AWS SDK 库的影响。

《Spring Cloud Stream Binder for AWS Kinesis》项目也存在同样的问题。在原生 AWS Kinesis 服务和 KCL/KPL 之间以及匹配 Spring Cloud Stream 版本之间的选择导致了一些依赖管理方面的麻烦。

这些 Spring 项目从未计划与主项目合并，成为 Spring Integration 和 Spring Cloud Stream 中的模块，也未成为任何发布列车的一部分。大多数重用的 API 和自动配置都是从 Spring Cloud AWS 项目中提取的，这导致了发布周期上的差异，因为后者本身依赖于 Spring Boot 和 Spring Cloud。

我们和你们双方的这些日常工作，都是因为 Spring Cloud AWS 是一个完全由开源社区管理和支持的独立项目。即使它在 Spring Portfolio 旗下，由于依赖的复杂性，仍然会将 Spring Integration AWS 和 Kinesis Binder 项目排除在我们的发布列车之外。

随着即将到来的 7.0 代版本将于 11 月发布（Spring Boot 4.0 和 Spring Cloud 2025.1.0），我们决定不再为 Spring Integration AWS 和 Kinesis Binder 项目发布新的主版本。相反，我们将抓住整个产品组合主版本的机会，提供更合理、更易于管理和更易于使用的东西。Spring Integration AWS 和 Kinesis Binder 项目都将直接合并到Spring Cloud AWS中。

Spring 工程团队和 Spring Cloud AWS 社区之间的共同努力。目前的工作计划不是在 Spring Cloud AWS 中提供一个单一的 spring-cloud-aws-integraiton 模块，而是将 Spring Integration 通道适配器和组件分散到现有的 Spring Cloud AWS 模块中，例如 spring-cloud-aws-dynamodb 或 spring-cloud-aws-s3，并为这个或那个集成 AWS 服务提供带有所需依赖的专用启动器，例如 spring-cloud-aws-starter-integration-sqs 和 spring-cloud-aws-starter-integration-sns。请在 Spring Cloud AWS GitHub 问题和拉取请求中加入我们，分享有关此迁移过程的任何反馈。

即将发布的 Spring Cloud AWS 4.0，基于 Spring Boot 4.0 和 Spring Cloud 2025.1.0，将通过其直接的发布列车、细粒度的模块化和更简单的依赖管理模型，为 Spring Integration 和 Kinesis Binder 用户提供流畅的体验。合并完成后，Spring Integration AWS 和 Kinesis Binder 项目将在 GitHub 上归档，因为它们的开源支持已结束。

此致， 
Artem