Maven与SBT Assembly插件差异：为何前者打包成功后者冲突？

这是Maven转SBT时非常常见的坑，核心原因是两者生成fat jar的理念和默认行为完全不同，我来给你拆解清楚：

一、核心差异：Maven vs SBT Assembly的fat jar处理逻辑 #

1. Maven的默认打包（通常依赖Shade插件） #

如果你的Maven项目能通过mvn package生成fat jar，大概率是用了Shade插件。它的默认逻辑是尽量“自动抹平”冲突：

• 会借助Maven自带的依赖冲突自动调解机制（比如最短依赖路径、声明优先规则），先排除掉一部分重复依赖；
• 遇到重复类时，默认采用“覆盖”策略（保留最后被引入的版本的类），不会直接报错，除非你特意配置了严格检查。

2. SBT Assembly的默认逻辑 #

SBT Assembly的设计理念是**“零容忍”类重复**，它默认会严格校验所有要打包的类：

• 只要发现同一个全限定类名的文件内容不一样，就直接抛出合并错误，不会自动处理；
• 这种设计是为了避免你因为无意识的类版本冲突，导致运行时出现莫名其妙的Bug，但也意味着你必须手动处理所有冲突。

二、你的案例里的具体冲突 #

从报错信息看，你遇到了两类典型冲突：

1. Commons Logging桥接包 vs 原生包：astyanax-cassandra依赖jcl-over-slf4j（SLF4J对Commons Logging的桥接实现），而cassandra-all依赖原生的commons-logging，两个包都包含org.apache.commons.logging下的类，内容却不一致。
2. 同包不同GroupId的High-Scale-Lib：cassandra-all用的是com.github.stephenc.high-scale-lib:1.1.2，而astyanax-cassandra用的是com.boundary:high-scale-lib:1.0.6——这俩groupId不同，但包名、类名完全一致，版本内容却有差异，被SBT Assembly识别为重复类。

三、为什么Maven没报错？ #

大概率是这两个原因之一：

• Maven的依赖调解机制已经自动排除了其中一个冲突依赖（比如优先保留路径更短的版本）；
• Shade插件默认帮你覆盖了重复类，没有触发错误提示。

四、怎么解决SBT Assembly的问题？ #

你需要手动配置合并策略或者排除冲突依赖，这里给你两种可行方案：

方案1：在依赖中直接排除冲突项 #

修改build.sbt的依赖声明，主动排除掉冲突的依赖：

libraryDependencies ++= Seq(
  // 排除astyanax依赖的旧版本high-scale-lib
  "com.netflix.astyanax" % "astyanax-cassandra" % "3.9.0" exclude("com.boundary", "high-scale-lib"),
  // 排除cassandra-all依赖的原生commons-logging，用jcl-over-slf4j替代
  "org.apache.cassandra" % "cassandra-all" % "3.4" exclude("commons-logging", "commons-logging")
)

方案2：配置Assembly的合并策略 #

如果不想修改依赖，可以在build.sbt中指定重复类的处理规则：

assemblyMergeStrategy in assembly := {
  // 丢弃重复的META-INF文件（这类文件大多是签名、配置，重复了没用）
  case PathList("META-INF", xs @ _*) => MergeStrategy.discard
  // 遇到commons-logging的类，保留第一个找到的版本（也就是jcl-over-slf4j的）
  case PathList("org", "apache", "commons", "logging", xs @ _*) => MergeStrategy.first
  // 遇到high-scale-lib的类，保留第一个找到的（也就是cassandra-all带的高版本）
  case PathList("org", "cliffc", "high_scale_lib", xs @ _*) => MergeStrategy.first
  // 其他类用默认策略处理
  case x => MergeStrategy.defaultMergeStrategy(x)
}

两种方案都能解决你遇到的39个合并错误，推荐优先用方案1，因为主动排除依赖比事后合并更清晰，能避免潜在的隐藏问题。

内容的提问来源于stack exchange，提问作者Atais