netty 依赖带来旧版本
netty dependency brings old version
我正在使用 grpc-netty 的最新依赖项。
问题是它带来了旧版本的 io.netty 依赖项 (4.1.27)
我查看了grpc-netty项目,使用的io.netty依赖版本是4.1.63。
知道让这种依赖关系带来旧版本传递依赖关系的原因是什么吗?
谢谢
<dependency>
<groupId>xxx</groupId>
<artifactId>xxx</artifactId>
<exclusions>
<exclusion>
<groupId>io.netty</groupId>
<artifactId>netty-codec-http2</artifactId>
</exclusion>
</exclusions>
</dependency>
您需要排除标签
Maven 在选择依赖的版本时不比较版本号。它只是选择执行 breadth-first 搜索时遇到的第一个版本。出于这个原因,gRPC 团队强烈 recommends 使用 Maven 执行器 requireUpperBoundDeps
让你 检测 像你面临的问题:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.4.1</version>
<executions>
<execution>
<id>enforce</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireUpperBoundDeps/>
</rules>
</configuration>
</execution>
</executions>
</plugin>
然后,有两种方法可以解决问题:
- 重新排序依赖列表或re-define传递依赖
- 使用 BOM
(1) 以 Maven 的 breadth-first 搜索为目标,让 Maven 的搜索首先“看到”您想要的版本。例如,您可以在 <dependencies>
中重新排序 netty-handler
before grpc-netty
,然后 Maven 将首先遇到它并选择它在 [=14 之前的直接依赖项=] 的直接依赖。当您无法重新排序来解决问题时,您可以添加对传递依赖项的显式依赖以明确选择其版本。例如,您可以在 <dependencies>
.
中添加 netty-resolver
with version 4.1.51.Final
(2) 适用于 multi-artifact 项目,如 gRPC 和 Netty,您确实希望这些项目的各种工件的版本一致。您通常不想将 netty-buffer
4.1.51.Final 与 netty-codec-http2
4.1.27.Final 一起使用;你想要他们相同的版本。在这些情况下,您可以检查项目是否有 BOM。 gRPC 和 Netty 都有 BOM。使用 BOM,您将 select 该版本用于该项目中的所有各种工件。 BOM 在 <dependencyManagement>
部分中定义,该部分与 <dependencies>
.
分开
<dependencyManagement>
<dependencies>
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-bom</artifactId>
<version>4.1.51.Final</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
...
无论做什么,都不要排斥。排除在以后会导致依赖性问题,因为它们隐藏了传递性依赖性。如果较新版本的 gRPC 依赖于 较新 版本的 Netty,那么您最终会 降级 Netty。那时构建工具无法再检测或管理问题;您只会在运行时发现此类问题。
从您所展示的内容可以清楚地看出,您的 pom.xml 中还发生了更多事情;你真的需要分享更多你的 pom 来诊断。但是其他答案告诉你排除我想展示更合适的解决方法。
我正在使用 grpc-netty 的最新依赖项。
问题是它带来了旧版本的 io.netty 依赖项 (4.1.27)
我查看了grpc-netty项目,使用的io.netty依赖版本是4.1.63。
知道让这种依赖关系带来旧版本传递依赖关系的原因是什么吗?
<dependency>
<groupId>xxx</groupId>
<artifactId>xxx</artifactId>
<exclusions>
<exclusion>
<groupId>io.netty</groupId>
<artifactId>netty-codec-http2</artifactId>
</exclusion>
</exclusions>
</dependency>
您需要排除标签
Maven 在选择依赖的版本时不比较版本号。它只是选择执行 breadth-first 搜索时遇到的第一个版本。出于这个原因,gRPC 团队强烈 recommends 使用 Maven 执行器 requireUpperBoundDeps
让你 检测 像你面临的问题:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.4.1</version>
<executions>
<execution>
<id>enforce</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireUpperBoundDeps/>
</rules>
</configuration>
</execution>
</executions>
</plugin>
然后,有两种方法可以解决问题:
- 重新排序依赖列表或re-define传递依赖
- 使用 BOM
(1) 以 Maven 的 breadth-first 搜索为目标,让 Maven 的搜索首先“看到”您想要的版本。例如,您可以在 <dependencies>
中重新排序 netty-handler
before grpc-netty
,然后 Maven 将首先遇到它并选择它在 [=14 之前的直接依赖项=] 的直接依赖。当您无法重新排序来解决问题时,您可以添加对传递依赖项的显式依赖以明确选择其版本。例如,您可以在 <dependencies>
.
netty-resolver
with version 4.1.51.Final
(2) 适用于 multi-artifact 项目,如 gRPC 和 Netty,您确实希望这些项目的各种工件的版本一致。您通常不想将 netty-buffer
4.1.51.Final 与 netty-codec-http2
4.1.27.Final 一起使用;你想要他们相同的版本。在这些情况下,您可以检查项目是否有 BOM。 gRPC 和 Netty 都有 BOM。使用 BOM,您将 select 该版本用于该项目中的所有各种工件。 BOM 在 <dependencyManagement>
部分中定义,该部分与 <dependencies>
.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-bom</artifactId>
<version>4.1.51.Final</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
...
无论做什么,都不要排斥。排除在以后会导致依赖性问题,因为它们隐藏了传递性依赖性。如果较新版本的 gRPC 依赖于 较新 版本的 Netty,那么您最终会 降级 Netty。那时构建工具无法再检测或管理问题;您只会在运行时发现此类问题。
从您所展示的内容可以清楚地看出,您的 pom.xml 中还发生了更多事情;你真的需要分享更多你的 pom 来诊断。但是其他答案告诉你排除我想展示更合适的解决方法。