【问题标题】:Why maven uses older version when there is a conflict between child projects?当子项目之间存在冲突时,为什么maven使用旧版本?
【发布时间】:2018-10-12 00:31:19
【问题描述】:

在有一个子模块 testA 依赖于 vaadin-client-compiler 依赖于 commons-lang3 3.1 版,它还依赖于另一个子模块 testB 依赖于 commons-lang3 3.4 版。

我希望 testA 使用 3.4 版本,因为 testB 依赖于它,但它使用 3.1 版本。我可以通过将[] 添加到testB 项目中的版本来解决它,但为什么会这样呢?为什么maven不强制不解析正确的版本?

MCVE:

家长:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>test</groupId>
    <artifactId>test</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>test</name>
    <packaging>pom</packaging>
    <modules>
        <module>testB</module>
        <module>testA</module>
    </modules>
</project>

依赖的孩子

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>test</groupId>
    <artifactId>test</artifactId>
    <version>0.0.1-SNAPSHOT</version>
  </parent>
    <dependencies>
        <dependency>
            <groupId>com.vaadin</groupId>
            <version>7.6.8</version>
            <artifactId>vaadin-client-compiler</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
  <groupId>testB</groupId>
  <artifactId>testB</artifactId>
        <version>0.0.1-SNAPSHOT</version>
        </dependency>
    </dependencies>
  <groupId>testA</groupId>
  <artifactId>testA</artifactId>
</project>

还有受抚养的孩子

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>test</groupId>
    <artifactId>test</artifactId>
    <version>0.0.1-SNAPSHOT</version>
  </parent>
  <groupId>testB</groupId>
  <artifactId>testB</artifactId>
  <dependencies>
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-lang3</artifactId>
            <version>3.4</version>
        </dependency>
  </dependencies>
</project>

【问题讨论】:

  • 你应该在父pom中设置依赖管理并在那里管理版本。
  • @PaulBastide 这是一个 MCVE,我的实际项目更复杂。就像我在问题中所说的那样,我有一个解决方案,我在问为什么会发生这种情况。
  • @PaulBastide 即使有这个例子,我也不同意你的建议。我在testB 中使用并需要 3.4 版本,这就是应该指定的地​​方,我没有在其他模块的任何其他地方使用它。 vaadin-client-compiler 在遇到这个问题之前我什至都没有意识到需要它。
  • 为什么我的投票失败了?这真的伤害了我的感情。
  • 解决方案是使用@PaulBastide 提到的dependencyManagement,答案中给出了解释......

标签: java maven maven-reactor


【解决方案1】:

根据Maven Documentation

[Maven] 将使用依赖树中与您的项目最接近的依赖版本。

如果两个依赖版本在依赖树中的深度相同,在 Maven 2.0.8 之前没有定义哪个会获胜,但从 Maven 2.0.9 开始,重要的是声明中的顺序:第一个声明获胜.

因此,您的问题的答案是 - 因为您在 testB 依赖项之前定义了 vaadin-client-compiler 依赖项,并且对 commons-lang3 的依赖项与 testA 在树中的深度相同。

如果您颠倒 testA 中依赖项的顺序,您会看到它现在提取了 commons-lang3 的 3.4 版本(假设您使用的是 2.0.9 或更高版本的 Maven)

【讨论】:

  • 谢谢,出于某种原因,我认为 maven 会考虑依赖项的版本并使用后者,这就是我实现它的方式。如果以这种方式完成,则破坏的可能性较小。
  • 不客气,但我不确定使用最新版本是否能显着降低出现问题的风险。这实际上取决于开发人员如何编写代码以及他们是否计划和测试向后兼容性。
猜你喜欢
  • 2013-11-08
  • 1970-01-01
  • 2015-11-22
  • 1970-01-01
  • 1970-01-01
  • 2014-01-23
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多