Question

我正在使用Maven来管理我的项目依赖项。我的依赖树在包B上有冲突，如：

A -> B (v1.4)
C -> B (v1.5)

事实证明，包A取决于v1.5中修复的错误，包C需要1.5中不是1.4的功能。

具有大量依赖关系的大型Java项目如何管理这些类型的问题？即使包装A似乎在v1.5的表面层面上工作，我仍然觉得在所有边缘情况下假设它将像以前一样工作会有风险。

请注意，这是一种假设情况，因此无需知道这些代码包含哪些包。

Answer 1

只有Maven和经典的罐子，没有任何结果：这就是为什么我们称之为＆＃34;依赖地狱＆＃34; （＆＃34; dll hell＆＃34;是原作，注意押韵:)。

然而，是一种致力于解决这个问题的技术：OSGi。通过大量复杂和复杂的类加载器杂耍，OSGi设法满足每个捆绑包的特定依赖要求。 Bundle A可以使用Bundle B v1.4，同时Bundle C可以使用B v1.5。

OSGi已经存在了十多年了，它似乎既不茁壮成长也不会消亡;相反，它正在以冰川的速度获得采用，因此越来越多的JAR升级到OSGi捆绑包。

Answer 2

最后只有一个依赖项在运行时生效，您可以使用<exclude>和<optional>来控制传递依赖项

<optional> and <exclude>

Answer 3

每当依赖项出现冲突时，Maven会根据 nearest-wins策略选择一个版本，这意味着将选择依赖树中更接近模块的版本，并且其他版本将被忽略。如果v1.4在依赖关系树中更近，则会选择它，即使它早于v1.5。

要控制要使用的依赖项，可以在模块中定义dependencyManagement以设置Maven应使用的版本：

<dependencyManagement>
   <dependencies>
      <dependency>
         <groupId>com.example</groupId>
         <artifactId>packageB</artifactId>
         <version>1.5</version>
      </dependency>
      <!-- other dependencies -->
   </dependencies>
</dependencyManagement>

或者，您可以在依赖于它的依赖项中排除要忽略的版本：

<dependency>
   <groupId>com.example</groupId>
   <artifactId>packageA</artifactId>
   <exclusions>
      <exclusion>
         <groupId>com.example</groupId>
         <artifactId>packageB</artifactId>
      </exclusion>
   </exclusions>
</dependency>

Answer 4

这不是maven问题 - 它是一个java问题。 Maven只是暴露它并使识别和管理问题成为可能。有许多解决方案：大多数（如果不是全部）解决方案都是作为独立的类加载器实现的，通常是在Java EE或OSGi容器中。

另外：作为一般规则，不要在项目中允许传递依赖 - 如果使用类，则将第一类依赖项添加到它所属的库中。至少在这种情况下，很容易看出你的依赖关系在哪里，以及你的问题可能存在的地方。

没有工作解决方案的Java传递依赖问题

4 个答案: