maven exclusion 解决maven传递依赖中的版本冲突

传递依赖是maven最有特色的、最为方便的优点之一，可以省了很多配置。如a 依赖 b,b 依赖c 默认 a也会依赖 c。但是也会带来隐患，如版本冲突。当然maven也考虑到解决办法，可以使用exclusions来排除相应的重复依赖。

但是我们还会遇到一个严重的问题，那就是，我怎么知道是哪个包的传递依赖产生的冲突 ？那该怎么办呢？当然，maven也会有相应的解决方案。

首先，你要在pom.xml中加上maven-project-info-reports-plugin插件。

<reporting> 
<plugins> 
<plugin> 
<groupId>org.apache.maven.plugins</groupId> 
<artifactId> 
maven-project-info-reports-plugin 
</artifactId> 
</plugin> 
</reporting>

然后再执行：mvn project-info-reports:dependencies 。生成项目依赖的报表，这样你就能够在报表中找出你版本冲突的相关性依赖了。如出现OutOfMemoryError错误，在系统环境中加入参数 MAVEN_OPTS=-Xmx512m

最后在相应的dependency中加上exclusions来排除相关的传递依赖。

例：

<dependency> 
<groupId>jaxen</groupId> 
<artifactId>jaxen</artifactId> 
<version>1.1.1</version> 
<exclusions> 
<exclusion> 
<groupId>com.ibm.icu</groupId> 
<artifactId>icu4j</artifactId> 
</exclusion> 
</exclusions> 
<scope>runtime</scope> 
</dependency>

时间： 2024-10-07 22:18:28

maven exclusion 解决maven传递依赖中的版本冲突的相关文章

解决maven传递依赖中的版本冲突

首先在pom.xml中添加: <reporting> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId> maven-project-info-reports-plugin </artifactId> </plugin> </plugins> </reporting> 如果用的是eclip

httpclient版本冲突,maven工程中传递依赖导致的版本冲突

A服务发送http请求调用B服务时,出现异常信息:2020-03-23 10:15:14.001:WARN:oejs.ServletHandler:qtp760563749-27: org.springframework.web.util.NestedServletException: Handler processing failed; nested exception is java.lang.NoClassDefFoundError: org/apache/http/util/Argsat

Maven依赖jar包版本冲突解决方案

1.为何会产生依赖冲突 Maven中的传递性依赖机制,一方面简化了依赖声明,另一方面如果传递依赖有可能引发版本冲突.例如:有这样的依赖关系:a->b->c->x(1.0).a->d->x(2.0),对于这样的冲突Maven给出的方案是:第一原则:路径最近者优先,第二原则:在路径长度相等的前提下,pom中的依赖声明的顺序决定了谁会被解析. 2.如何排除依赖 pom如下: <dependency> ...... <exclusions> <exclu

施用 maven shade plugin 解决 jar 或类的多版本冲突

施用 maven shade plugin 解决 jar 或类的多版本冲突 使用 maven shade plugin 解决 jar 或类的多版本冲突java 应用经常会碰到的依赖的三方库出现版本冲突,下面举一个具体的例子. Dubbo 是一个分布式的服务框架,其中的一种 rpc 实现(dubbo 协议)使用 hessian 3.2.0 来做序列化,另外一种实现(hsf协议)同样使用了 hesssian,但使用的版本是 3.0.14.如果现在一个应用中同时使用了 dubbo 协议和 hsf 协议

spring maven项目解决依赖jar包版本冲突方案

引入:http://blog.csdn.net/sanzhongguren/article/details/71191290 在spring reference中提到一个解决spring jar包之间版本冲突的解决方案,原文如下 It is possible to accidentally mix different versions of Spring JARs when using Maven. For example, you may find that a third-party lib

maven 的作用域和传递依赖问题

maven的作用域共有五个: (1) compile   默认就是compile,什么都不配置也就是意味着compile.compile表示被依赖项目需要参与当前项目的编译,当然后续的测试,运行周期也参与其中,是一个比较强的依赖.打包的时候通常需要包含进去. (2)   test   scope为test表示依赖项目仅仅参与测试相关的工作,包括测试代码的编译,执行.比较典型的如junit. (3)   runntime  runntime表示被依赖项目无需参与项目的编译,不过后期的测试和运行周期

centos中JDK版本冲突的问题

在centos环境下,我JDK版本安装了jdk6,jdk7.系统还自带了一个JDK7. 我在查看JDK版本是,发现不是我在/etc/profile中配置的. 1:which java 查看Java的命令使用哪的: /usr/bin/java 2:ll  /usr/bin/java lrwxrwxrwx 1 root root 22 3月  16 11:38 /usr/bin/java -> /etc/alternatives/java 3: ll  /etc/alternatives/java

转】Maven实战（七）---传递依赖

原博文出自于:http://blog.csdn.net/liutengteng130/article/details/47000069   感谢! 假设A-->C  B-->A      ==> B-->C ,A依赖于C是直接依赖,B依赖于A是直接依赖,B依赖于C是传递依赖. 现象一 举个例子:A-->log1.0  B-->log2.0 C-->A,B 那么我们来看依赖关系: User-core依赖于log4j 1.2.17 <dependency>

Maven实战（七）---传递依赖

假设A-->C  B-->A      ==> B-->C ,A依赖于C是直接依赖,B依赖于A是直接依赖,B依赖于C是传递依赖. 现象一 举个例子:A-->log1.0  B-->log2.0 C-->A,B 那么我们来看依赖关系: User-core依赖于log4j 1.2.17 <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifact