排除并重新导入Maven依赖项,使用不同的版本。

huangapple go评论58阅读模式
英文:

Excluding and Reimporting a Maven Dependency with Different Version

问题

这个例子是基于一个现实世界的问题构想出来的假设情景。考虑一个从 pom.xml 文件中提取的代码块如下。在这种情况下,我想要从 artifact-a 中排除 artifact-b 依赖项,并以不同的版本重新导入它。显然,被排除的 artifact-b 版本不等于 ${product2.version}

<dependency>
    <groupId>com.company.product1</groupId>
    <artifactId>artifact-a</artifactId>
    <version>${product1.version}</version>
    <exclusions>
        <exclusion>
            <groupId>com.company.product2</groupId>
            <artifactId>artifact-b</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>com.company.product2</groupId>
    <artifactId>artifact-b</artifactId>
    <version>${product2.version}</version>
</dependency>

因此,当执行 mvn install 命令来构建最终应用程序时,我将只在应用程序存储从其依赖项收集的 JAR 文件的文件夹下找到 artifact-b${product2.version}

这是我的模块的预期行为,但这是否意味着 artifact-a JAR 文件中的方法现在将使用 ${product2.version} 调用 artifact-b JAR 文件中的方法?如果是这样的话(这是我期望的,因为目标仓库不包括被排除的版本),如果新版本中被调用的 artifact-b 中的方法不同会发生什么?它只检查方法签名还是还有其他因素可能引发编译/运行时错误?

英文:

This example is a hypothetical scenario based on a real-world problem. Consider a block taken from a pom.xml file as given below. In this scenario, I want to exclude artifact-b dependency from artifact-a and reimport it with a different version. Obviously, excluded artifact-b version is not equal to ${product2.version}.

<dependency>
    <groupId>com.company.product1</groupId>
    <artifactId>artifact-a</artifactId>
    <version>${product1.version}</version>
    <exclusions>
        <exclusion>
            <groupId>com.company.product2</groupId>
            <artifactId>artifact-b</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>com.company.product2</groupId>
    <artifactId>artifact-b</artifactId>
    <version>${product2.version}</version>
</dependency>

Thus, when mvn install command is executed for the final application, I will only have the artifact-b with ${product2.version} under the folder where the application stores the jars collected from its dependencies.

This is the expected behaviour for my module, but does it also mean that the methods in artifact-a jar will now make calls to the artifact-b jar with ${product2.version}? If so (which is what I expect since target repository does not include the excluded version), what happens if the called method in artifact-b is different in the new version? Does it only check method signatures or are there other factors that can cause compilation/runtime errors?

答案1

得分: 1

First of all, as khmarbaise said, the exclusion is unnecessary.
首先,正如khmarbaise所说,排除是不必要的。

Secondly, increasing the library version can cause all kinds of problems. The compile time problems are mainly method signatures or missing classes, but at runtime, anything can happen, depending on the changes made in the source code of that library.
其次,增加库的版本可能会引发各种问题。编译时的问题主要是方法签名或缺少类,但在运行时,根据库的源代码更改,任何事情都可能发生。

You can just hope that the maintainers of the library tried to keep everything backwards compatible.
你只能希望库的维护者尽力保持一切向后兼容。

英文:

First of all, as khmarbaise said, the exclusion is unnecessary.

Secondly, increasing the library version can cause all kinds of problems. The compile time problems are mainly method signatures or missing classes, but at runtime, anything can happen, depending on the changes made in the source code of that library.

You can just hope that the maintainers of the library tried to keep everything backwards compatible.

huangapple
  • 本文由 发表于 2020年8月13日 03:53:03
  • 转载请务必保留本文链接:https://go.coder-hub.com/63383831.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定