Camunda Optimize 7 中排除 Spring Beans 依赖的技术解析

背景与问题

在 Camunda Optimize 7（版本 3.12-3.15）中，由于 Camunda 引擎（版本 7.20-7.22）的传递依赖，系统引入了 Spring 5 的相关组件。然而，Spring 5 已经进入生命周期终止（EOL）阶段，不再获得官方支持。更关键的是，Optimize 7 实际上并不需要使用这些传递依赖的 Spring Beans 组件，因为系统本身已经直接依赖了 Spring Framework 6。

这种情况导致了两个主要问题：

1. 安全扫描工具会将这些过期的 Spring 5 依赖标记为潜在的安全问题
2. 系统中存在多余的依赖，增加了依赖管理的复杂性

技术解决方案

开发团队通过修改项目构建文件（pom.xml），显式排除了 Camunda 引擎中传递引入的 Spring Beans 依赖。这种做法类似于之前对 FEEL 引擎和 Commons Logging 依赖的处理方式。

这种排除操作的核心在于：

1. 精确识别不需要的传递依赖
2. 在依赖声明中明确排除这些组件
3. 确保排除操作不会影响系统正常运行

实现细节

在 Optimize 的后端模块构建配置中，开发团队添加了特定的排除规则。这些规则确保了在引入 Camunda 引擎依赖时，相关的 Spring Beans 组件不会被自动引入。

这种处理方式的优势在于：

• 保持了系统的功能完整性
• 消除了多余的依赖
• 解决了安全扫描工具的误报问题
• 简化了依赖树结构

兼容性考虑

值得注意的是，虽然排除了 Spring 5 的依赖，但系统仍然保持了对 Spring Framework 6 的直接依赖。这种设计确保了：

1. 系统功能的完整性不受影响
2. 用户仍然可以使用 Spring 的最新特性
3. 系统安全性得到提升

临时解决方案

在正式修复发布前，用户可以通过手动覆盖 Spring 版本到 6.1.15+ 来临时解决这个问题。这种方法虽然可行，但不如官方修复方案优雅和可靠。

总结

Camunda Optimize 7 中排除 Spring Beans 依赖的优化，展示了如何通过精细的依赖管理来解决技术债务和安全问题。这种处理方式不仅解决了当前的安全警告问题，还为系统的长期维护打下了更好的基础。对于使用类似技术栈的项目，这种依赖管理的思路也值得借鉴。

通过这种优化，Camunda Optimize 7 用户可以获得更安全、更简洁的依赖结构，同时避免了因使用过时组件可能带来的潜在风险。