How to solve sbt dependency conflict?

187 Views Asked by At

I have this error when doing sbt clean assembly:

deduplicate: different file contents found in the following:
[error] /home/jack/.cache/coursier/v1/https/repository.rnd.transport.net/adata-sbt-producdataon/com/transport/data/data-scalaxb-abr_2.11/1.0.1/data-scalaxb-abr_2.11-1.0.1.jar:scalaxb/XMLStandardTypes$class.class
[error] /home/jack/.cache/coursier/v1/https/repository.rnd.transport.net/adata-sbt-producdataon/com/transport/data/data-scalaxb-datackedatang_2.11/0.12.0/data-scalaxb-datackedatang_2.11-0.12.0.jar:scalaxb/XMLStandardTypes$class.class
at sbtassembly.Assembly$.applyStrategies(Assembly.scala:142)
[error]         at sbtassembly.Assembly$.x$1$lzycompute$1(Assembly.scala:26)
[error]         at sbtassembly.Assembly$.x$1$1(Assembly.scala:24)
[error]         at sbtassembly.Assembly$.stratMapping$lzycompute$1(Assembly.scala:24)
[error]         at sbtassembly.Assembly$.stratMapping$1(Assembly.scala:24)
[error]         at sbtassembly.Assembly$.inputs$lzycompute$1(Assembly.scala:68)
[error]         at sbtassembly.Assembly$.inputs$1(Assembly.scala:58)
[error]         at sbtassembly.Assembly$.apply(Assembly.scala:85)

To solve this problem, i have tried added one of these blocks in build.sbt:

assemblyMergeStrategy in assembly := {
  case PathList("scalaxb", "XMLStandardTypes$class.class") =>
    MergeStrategy.first
  case x =>
    val oldStrategy = (assemblyMergeStrategy in assembly).value
    oldStrategy(x)
}

, or

libraryDependencies += ("com.transport.data" %% "data-scalaxb-datackedatang" % "0.12.0")
  .exclude("scalaxb", "XMLStandardTypes$class.class")

Nothing works.

I understand that there exist two versions of XMLStandardTypes class coming from data-scalaxb-abr and data-scalaxb-datackedatang, but even after i tried to use the merge strategy first (or last, or discard), or even exclude, why it still persists? How can I solve this problem?


Update1: It seems it happens in some machines but not some other machines, the merge behaviour depends on the machines. It happens in several local machines, but not in Jenkins agent. Does it give a hint?

0

There are 0 best solutions below