依赖冲突解决办法

  • Z时代
  • 2024-01-10
  • 分类：综合

编程

maven 的价值

Java开发中，jar的管理由maven来管。maven做的事情：

  • jar统一管理： jar 包统一管理在仓库中。统一管理自然要给每个jar包进行“编址”，它主要采用 groupId+artifactId+version三级寻址方案（当然也有classifier）。统一管理带来好处的同时，带来了麻烦，麻烦是仓库是“单点”，为了避免这个瓶颈，maven 客户端配置可以支持镜像仓库（mirrors）机制。

  • 依赖传递： 当我们的程序依赖A，我们引用A就好；但是实际上A又依赖B和C，我们不用再琐碎的依赖B和C了，这个maven会解析A中的pom.xml，并传递的拉取子级依赖。

“依赖传递”让开发者省去很多琐碎的心思。但它方便的同时，可能带来一些麻烦——依赖冲突。

依赖冲突

所谓“依赖冲突”如下图所示：

 

依赖冲突.jpg

图中，我们的程序依赖A，那么我们在pom.xml中配置：

<dependency>
<groupId>org.example</groupId>
<artifactId>A</artifactId>
<version>${version}</version>
</dependency>

实际上，A它依赖B和C （这个在A的pom.xml中会有描述）。B再依赖X和Y；C依赖Y和Z。其中Y是B和C的共同依赖，只不过B依赖Y的1.0版本，而C依赖Y的2.0版本。

问题来了：maven应该选择Y的1.0版本，还是2.0版本呢？

答案：maven肯定需要给出一个决策顺序机制，来解决这个依赖冲突的问题。但这个机制即使我们知道了，实际工作中还是经常忘记，索性不想知道了。我们把握3点：

  • 依赖冲突发现：能够查看出当前项目中存在依赖冲突。

  • 决策结果查看：我不想知道决策顺序是什么，但我必须知道决策结果。

  • 调整决策结果: 可以让我们手动干预决策结果。比如上图的，我们可以自由选择Y-1.0.jar 还是 Y-2.0.jar 。

当然如果maven足够智能那当然更好，它能自动选择一个满足运行的决策，并把这个决策告诉ClassLoader。

顺便说一下，有没有可能冲突不可调和呢？当然可能，完全取决于Y是否遵守发版的基本原则：新版本兼容老版本。

如何实战上述的3点呢？ 用个Java开发过程中，经常可能发生的实际例子——slf4j的依赖冲突。

slf4j 实例

运行异常

程序运行时，出了个这样的异常：

Caused by: java.lang.NoSuchMethodError: org.slf4j.helpers.MessageFormatter.format(Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/String;
    at org.slf4j.impl.Log4jLoggerAdapter.info(Log4jLoggerAdapter.java:318)
    at org.hibernate.annotations.common.Version.<clinit>(Version.java:37)

这个异常说的是hibernate的annotations的某个类，在用slf4j输出日志的时候，发现NoSuchMethodError异常：org.slf4j.helpers.MessageFormatter类缺少format(Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/String方法。

我们ctrl+shift+T在Eclipse查看下org.slf4j.helpers.MessageFormatter类的，并ctrl+O找到format方法，发现的确没有参数为format(String[] , Object[])的方法，有的只是format(String, Object)方法。如下图所示：

 

NoSuchMethodError.png

的的确确slf4j缺少了那个方法。接着我们应该看看这个项目中有多少个jar依赖了slf4j，再仔细看看hibernate的annotations依赖的slf4j的版本。

依赖冲突发现

“依赖冲突发现”有两个技能，一个是可视化，另一个是命令行。
可视化技能：在Eclipse选择pom.xml，查看“Dependency Hierarchy”：

 

Dependency Hierarchy.png

可以看到hibernate-annotations依赖的版本是1.5.8，而xmemcached依赖的是1.5.6。maven现有决策机制把1.5.6排在前面，hibernate的显示“omitted for conflict with 1.5.6”。

到这可以看出，问题应该出在：hibernate原本要依赖高版本的1.5.8，而却被决策依赖到1.5.6了。

顺便说一下，命令行方式：

mvn dependency:tree      // 显示依赖结构
mvn dependency:tree -Dverbose    // 详细显示，路径更深
mvn dependency:tree -Dverbose -Dincludes=org.slf4j   // 如果太多，可以筛选
mvn dependency:tree -Dverbose -Dincludes=org.slf4j -Dexcludes=org.hibernate   // 还可以排除

决策结果查看

在“在Eclipse选择pom.xml，查看‘Dependency Hierarchy’”的图片中已经可以看到决策结果了。被忽略的会显示“omitted for conflict with XXX”。

当然也可以在JAVA启动的时候，增加JVM参数：-verbose:class。这样ClassLoader加载Class的时候就会有日志输出。

在一堆日志中，查找slf4j：

[Loaded org.slf4j.LoggerFactory from file:~/.m2/repository/org/slf4j/slf4j-api/1.5.6/slf4j-api-1.5.6.jar]

调整决策结果

排除 xmemcached 依赖的 slf4j：

 

Exclude Maven Artifact.png

界面操作完后，对应的pom.xml被自动编辑为（注意exclusion标签）：

<dependency>
<groupId>com.googlecode.xmemcached</groupId>
<artifactId>xmemcached</artifactId>
<version>${xmemcached.version}</version>
<exclusions>
<exclusion>
<artifactId>slf4j-api</artifactId>
<groupId>org.slf4j</groupId>
</exclusion>
</exclusions>
</dependency>

调整后，用上面说的方法，再次验证一下决策结果。

全局排除

有了exclusion机制，冲突问题就基本能解决了（当然前提是冲突的那个jar，新版本能兼容老版本）。接着思考一个问题：我们刚刚从xmemcached排除了slf4j，以后其他人引用一个新包，比如叫abc.jar，它也依赖了slf4j，我们再排除一遍？要知道slf4j如此流行，许多包都会依赖它，于是我们每次加一个新jar都要去排除一遍？我们可以这么勤快去做。但万一哪次没排除，我们还一时不好发现，因为即便新jar引入一个低版本的slf4j，也得在运行时运行到需要高版本的分支问题才能暴露。我们会反反复复的去折腾这个日志问题。

于是我们想：

  • 版本去留：有没有一种机制能一次性排除slf4j，排除其他所有版本，只保留我们给定的版本”。

  • 严禁引入: slf4j有许多binding实现，可以logback，也可以log4j，还可以其他。假设我们期望选择log4j，后面的人一不小心偷偷引入logback应该被发现，被禁止。

社区里有先行者为大家做了插件：maven-enforcer-plugin，里面有个配置项bannedDependencies来管理这些。例如：

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.4.1</version>
<executions>
<execution>
<id>default-enforce</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<bannedDependencies>
<excludes>
<exclude>org.slf4j:*</exclude>
<exclude>ch.qos.logback:*</exclude>
<exclude>org.springframework:*</exclude>
</excludes>
<includes>
<include>org.slf4j:slf4j-api</include>
<include>org.slf4j:slf4j-log4j12</include>
<include>org.springframework:*:${spring.version}</include>
</includes>
</bannedDependencies>
</rules>
</configuration>
</execution>
</executions>
</plugin>

通过<exclude>org.slf4j:*</exclude>排除所有的slf4j，在通过<include>org.slf4j:slf4j-api</include>和<include>org.slf4j:slf4j-log4j12</include>保留住slf4j-api和log4j12，如果需要指定版本，可以<include>org.slf4j:slf4j-api:1.7.7</include>。另外对于binding，通过<exclude>ch.qos.logback:*</exclude>来禁止任何logback的引入。

配置完后，执行mvn validate或者mvn clean package的时候，如果违背了上述规则，就会报告：

[WARNING] Rule 0: org.apache.maven.plugins.enforcer.BannedDependencies failed with message:
Found Banned Dependency: ch.qos.logback:logback-classic:jar:1.1.2
Found Banned Dependency: org.slf4j:log4j-over-slf4j:jar:1.7.7
Found Banned Dependency: ch.qos.logback:logback-core:jar:1.1.2
Found Banned Dependency: org.springframework:spring-test:jar:2.5.6
Use "mvn dependency:tree" to locate the source of the banned dependencies.

这样我们再通过前面讲的exclusion机制来排除。

提醒

maven-enforcer-plugin不会自动排除，但会提供一个规则检测机制。然后谁加入，谁排除。

遭遇“流氓”

按理有了maven-enforcer-plugin冲突问题都可以很好解决。但笔者接下来要分享一个“流氓”事件——不遵守maven发布规则的人发布的jar。

如下一段非常简单的代码，就是用slf4j输出一行日志：

importorg.slf4j.Logger;
importorg.slf4j.LoggerFactory;
publicclassLogDemo{
privatestaticfinalLogger LOG =LoggerFactory.getLogger(LogDemo.class);
publicstaticvoidmain(String[] args)throwsException{
        LOG.info("HelloWorld");
}
}

运行时，报了一个异常：

SLF4J: This version of SLF4J requires log4j version 1.2.12 or later. See also http://www.slf4j.org/codes.html#log4j_version
Exception in thread "main" java.lang.NoSuchFieldError: TRACE
    at org.apache.log4j.Logger.isTraceEnabled(Logger.java:209)
    at org.slf4j.impl.Log4jLoggerAdapter.isTraceCapable(Log4jLoggerAdapter.java:83)
    at org.slf4j.impl.Log4jLoggerAdapter.<init>(Log4jLoggerAdapter.java:78)
    at org.slf4j.impl.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:68)
    at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:277)
    at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:288)
    at LogDemo.<clinit>(LogDemo.java:8)

说的是“SLF4J 绑定 log4j时，对 log4j 的版本要求是 1.2.12 或 以上”。

我们用上文提到过的Eclipse的“Dependency Hierarchy”查看log4j：

 

log4j的版本

 

如上图所示，log4j的版本是1.2.17 > 1.2.12，而且这个log4j还不是我们引入的，而是slf4j的log4j官方绑定 slf4j-log4j12 间接引入的（它的pom里面依赖了log4j）。显然这不会有版本问题。但的的确确就是异常了。

这时可以用 增加JVM参数 -verbose:class 来看加载的类。
再给一个简单的方法，那个异常说是org.apache.log4j.Level类有没有Trace属性，在Eclipse查下org.apache.log4j.Level`类（Ctrl+Shift+T）。会发现有两个jar``包都含有这个类。

 

两个jar含有log4j

第2个是我们想要的log4j，第1个是一个名叫"XXXclient-999-4.2.0.jar"的包里的log4j。看看这个jar，为了直观，我用可视化的方式看（你也可以 ``jar tvf XXXclient-999-4.2.0.jar | grep org.apache.log4j）：

 

不遵守标准的jar

没见过这么“流氓”的，依赖方式不是走pom.xml的dependency，而是直接log4j的源代码打包进来，必然导致maven管理不到它。

解决办法，把那个jar中关于log4j的东西删了，再手动打包发布一个新的4.3.0版本。

tar xvf XXX-client-4.2.0.jar
rm -rf org/apache
rm -rf log4j.properties
tar cvf XXX-client-4.3.0.jar .
mvn install:install-file -Dfile=XXX-client-4.3.0.jar -DgroupId=XXX.sdk -DartifactId=XXX-client -Dpackaging=jar -Dversion=4.3.0

如需发布到远程，请用deploy命令。

这个问题不是本文的主题，只顺带提一下。

以上是 依赖冲突解决办法 的全部内容， 来源链接： utcz.com/z/514717.html

回到顶部