netty依赖关系带来旧版本
我使用的是最近对grpc的依赖。问题是，它带来了较早版本的io.netty依赖项(4.1.27)，我在grpc项目中查看过，使用过的io.netty依赖项版本为4.1.63。知道有什么原因可以让这种依赖关系带来更老版本的传递依赖关系吗？
谢谢
回答 2
Stack Overflow用户
发布于 2022-02-12 09:53:49
<dependency>
<groupId>xxx</groupId>
<artifactId>xxx</artifactId>
<exclusions>
<exclusion>
<groupId>io.netty</groupId>
<artifactId>netty-codec-http2</artifactId>
</exclusion>
</exclusions>
</dependency>你需要排除标签
Stack Overflow用户
发布于 2022-02-14 15:52:39
当选择依赖项的版本时，Maven不比较版本号。它只是选择它在执行广度优先搜索时遇到的第一个版本。出于这个原因，gRPC团队强烈支持建议使用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>然后，要解决问题，有两种方法：
- 重新排序依赖项列表或重新定义传递依赖项
- 使用BOM
(1)以Maven的广度优先搜索为目标，通过Maven的搜索获得您希望首先“看到”的版本。例如，您可以在netty-handler中的grpc-netty之前重新排序Maven，然后Maven将首先遇到它，然后在grpc-netty的直接依赖项之前选择它的直接依赖项。当您无法重新排序以解决问题时，您可以在传递依赖项上添加一个显式依赖项来显式选择它的版本。例如，您可以在<dependencies>中添加4.1.51.Final版本的netty-resolver。
(2)适用于多工件项目，如gRPC和Netty，您确实希望各种工件的版本能够一致。您通常不希望在netty-buffer 4.1.27.Final中使用netty-codec-http2 4.1.51.Final；您希望它们具有相同的版本。在这些情况下，您可以检查项目是否有BOM。gRPC和Netty都有BOMs。使用BOM，您将为该项目中的所有工件选择一次使用的版本。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来进行诊断。但是其他的答案告诉你要排除，我想展示更合适的解决方法。
https://stackoverflow.com/questions/71088604
复制相似问题
腾讯云开发者
