processors项目中的sbt-assembly支持问题分析

processors项目中的sbt-assembly支持问题分析

在clulab/processors项目中，开发团队尝试为项目添加sbt-assembly支持时遇到了一个典型的多重依赖冲突问题。sbt-assembly是一个常用的SBT插件，用于将Scala项目及其所有依赖打包成一个独立的JAR文件，方便部署和分发。

问题现象

当执行sbt assembly命令时，构建过程失败并报告了108个错误。这些错误主要集中在JAR文件重复合并时的冲突问题。错误信息显示存在多个相同路径但内容不同的类文件，主要涉及jakarta.xml.bind和javax.xml.bind两个不同版本的XML绑定API。

典型的错误信息如下：

Deduplicate found different file contents in the following:
  Jar name = jakarta.xml.bind-api-2.3.3.jar
  Jar name = jaxb-api-2.2.7.jar
  Entry target = javax/xml/bind/helpers/Messages.properties

问题根源

这个问题本质上是Java生态系统中常见的依赖冲突问题。随着Java EE向Jakarta EE的迁移，许多包从javax命名空间迁移到了jakarta命名空间。在本项目中，同时引入了新旧两个版本的XML绑定API：

1. jakarta.xml.bind-api-2.3.3.jar (Jakarta EE版本)
2. jaxb-api-2.2.7.jar (Java EE版本)

这两个JAR包含有相同路径但实现不同的类文件，导致sbt-assembly在合并时无法自动决定应该保留哪个版本。

解决方案

对于这类问题，通常有以下几种解决方案：

1. 排除冲突依赖：在build.sbt中明确排除不需要的依赖版本
2. 依赖重定向：强制使用特定版本的依赖
3. 合并策略定制：为sbt-assembly配置自定义的合并策略

在processors项目中，最合理的解决方案是统一使用Jakarta EE版本的依赖，因为这是Java EE未来的发展方向。可以在build.sbt中添加如下配置：

assemblyMergeStrategy in assembly := {
  case PathList("javax", "xml", "bind", xs @ _*) => MergeStrategy.first
  case x =>
    val oldStrategy = (assemblyMergeStrategy in assembly).value
    oldStrategy(x)
}

这个配置告诉sbt-assembly在遇到javax.xml.bind路径下的文件冲突时，选择第一个遇到的版本（通常是Jakarta EE版本），而对于其他文件则保持默认的合并策略。

经验总结

1. 在迁移到新版本Java/Jakarta EE时，需要特别注意命名空间变化带来的依赖冲突
2. sbt-assembly的合并策略需要根据项目实际情况进行定制
3. 大型项目中的依赖管理需要更加谨慎，定期使用dependencyTree命令检查依赖关系
4. 对于过渡期的技术标准，项目应该明确选择使用新标准还是旧标准，避免混合使用

这个问题也提醒我们，在创建功能分支时，应该始终基于最新的主分支，以避免遗漏重要的变更。在processors项目中，mainclass分支是基于较旧的版本创建的，这可能导致了一些配置上的不一致。