我有一个项目X,它在依赖关系层次结构中显示了很多冲突的依赖关系(如Eclipse的依赖关系层次结构视图中所示)。我看到很多东西:
clojure: 1.3.0 (omitted for conflict with 1.4.0) [compile]
这通常是因为X使用的两个库指定了某些其他库的两个不同版本 - 即由于共享的传递依赖性而发生冲突。在很多情况下,冲突发生在我无法直接控制的第三方库中。
幸运的是,现在所有东西都建立并运行正常,但我担心这种情况可能会在将来引发问题。
这是一个我应该担心的问题,如果是这样,我应该怎么做呢?
答案 0 :(得分:4)
是的,这种冲突可能很严重。
在比较版本1时,您不知道依赖项中是否存在不兼容的更改(在比较次要版本时,不应该是谁,但谁知道确切?)。或许某些依赖性取决于另一个依赖项的错误行为。如果这个bug被修复了怎么办?那个依赖于bug的模块将无法正常执行。
您应该排除冲突的依赖项(更可能排除较低版本)。对于您输入的每个排除项,您必须检查排除的版本与当前使用的版本之间是否存在不兼容的更改。如果是这种情况,您必须检查依赖于该模块的依赖项,如果它们受此类更改的影响。
答案 1 :(得分:3)
大多数情况下,如果maven选择了较新的版本,这应该没问题。
如果主要版本(第一个数字)的差异发生冲突,或者如果省略了新版本,您应该开始担心。单元测试可以帮助解决这些问题,但是eclipse项目和maven依赖项通常以微妙的方式(调试范围等)不同。唯一真正的保护似乎是集成测试。
答案 2 :(得分:2)
它可以是一个严重的问题,因为你永远无法确定究竟会发生什么,这很糟糕。我认为使用maven配置的重点是明确发生了什么以及使用的依赖项。
至于你应该怎么做,请参阅我的other answer - 你应该通过明确配置要使用哪个版本以及遗漏哪个版本来推动修复它们,maven-enforcer plugin可以使用它DependencyConvergence rule更容易。这是为了保护您免受冲突的传递依赖。
答案 3 :(得分:0)
是的,这是一个问题。通常,不同的版本包含相同的类。最后,java仅加载该类的一个版本。它可能是旧版本,也可能是新版本。可能会导致运行时错误,例如神秘的NoSuchMethodError,ClassNotFoundExceptions等。