一.问题 项目开发过程中,经常会遇到jar冲突,然后maven根据自己的规则进行冲突解决,导致项目在运行的过程中报错. 1.maven自动解决依赖冲突的规则是什么? 2.如何查看当前项目的maven的依赖树? 3.如何从依赖树中找到自己预期的版本,是被那个jar给覆盖了? 4.如何人工进行依赖冲突解决,达到使用目的? 二.解决问题 1.maven自动解决依赖冲突的规则是什么? 第一原则:路径最近者优先 项目A有如下的依赖关系: A->B->C->X(1.0) A->D->X(

maven 检查依赖冲突和版本冲突   在项目发布的时候,一般都需要进行依赖冲突检查或者重复类的检查,这个时候我一般会使用下面的两个命令:   1 2 3 mvn -U clean package -Dmaven.test.skip=true enforcer:enforce -DcheckDeployRelease_skip=true -Denforcer.skip=false   mvn -U dependency:tree -Dverbose   dependency: tree是检查版本

mvn/maven如何检查依赖冲突,并解决依赖冲突 如图,点击图示位置,就可以把整个项目的依赖关系展示出来 在图里选中一个artifact,则所有依赖该artifact的地方都会一起连带出来突出显示,如果有不同版本的也会标记出来.这样该artifact在该工程里是如何被直接或间接引入的进来也就明朗了. 也可以在项目的pom.xml文件里,右键调出显示依赖关系的快捷键 如果有冲突的版本,可以右击该版本的节点然后Exclude,对应的pom.xml就已经成功修改了.(IntelliJ IDEA对于文

首先点击右侧的MavenProjects打开以下界面: 这个界面是maven的命令界面: 点击这个图标会进入如下界面: 左上角可以缩放,点击线可以取消冲突依赖,红色线为冲突依赖. 上图为无依赖冲突的smm框架.

如果项目中maven依赖太多,由于还有jar之间的间接依赖,所以可能会存在依赖冲突.依赖冲突大部分都是由于版本冲突引起的,查看maven的依赖关系,可以找到引起冲突的间接依赖 如上图,通过Dependency Hierachy可以查看到间接依赖,这里slf4j-api与其他引用的版本有冲突,我们可以exclude禁用这个间接依赖,代码如下: <dependency> <groupId>displaytag</groupId> <artifactId>disp

1 传递依赖冲突解决(了解) 传递依赖:A(项目)依赖B,B依赖C(1.1版本),B是A的直接依赖,C就是A的传递依赖 导入依赖D,D依赖C(1.2版本) 1.1 Maven自己调解原则 1.1.1 第一声明者优先原则 谁先定义的就用谁的传递依赖. 1.1.2 路径近者优先原则 直接依赖级别高于传递依赖. 1.2 排除依赖 1.3 版本锁定(推荐使用)   ====================dependencyManagement 是什么 Maven中的dependencyManageme

依赖冲突 若项目中多个Jar同时引用了相同的Jar时,会产生依赖冲突,但Maven采用了两种避免冲突的策略,因此在Maven中是不存在依赖冲突的. 短路优先 本项目-->A.jar-->B.jar-->X.jar 本项目-->C.jar-->X.jar 若本项目引用了A.jar,A.jar又引用了B.jar,B.jar又引用了X.jar,并且C.jar也引用了X.jar. 在此时,Maven只会引用引用路径最短的Jar. 声明优先 若引用路径长度相同时,在pom.xml中谁先

  在搭建web项目时,出现一个比较诡异的问题,任何JSP页面突然都不能够正常地显示,系统爆出HTTP:500(服务器内部错误)的页面   HTTP Status 500 - java.lang.NoSuchMethodError: org.eclipse.jdt.internal.compiler.CompilationResult.getProblems()[Lorg/eclipse/jdt/core/compiler/IProblem; type Exception report mess

使用maven 管理项目的依赖,可以使用如下命令查看依赖树结构: mvn dependency:tree 如下图是使用idea的终端执行命令的局部图: 也可以使用如下命令将输出定向到某个文件,这样就可以通过生成的文件来查看: mvn dependency:tree>tree.txt 执行后在项目根目录下有tree.txt文件 使用verbose参数可以看冲突和重复的具体情况: mvn dependency:tree>tree.txt -Dverbose 效果如下图

1.如图: 假设上图中的项目B引入了一个junit.jar架包是3.0的版本 项目D引入了一个junit.jar架包是4.0的版本,那么项目X引用的将会是4.0的版本 2.pom.xml排到最前面的架包优先: A—B—Cge A—N—Cge 假设项目B引入了一个junit.jar架包是3.0的版本 项目N引入了一个junit.jar架包是4.0的版本 项目C在pom.xml的依赖先后顺序如下: <project xmlns="http://maven.apache.org/POM/4.0.

什么是依赖冲突 依赖冲突是指项目依赖的某一个jar包,有多个不同的版本,因而造成类包版本冲突 依赖冲突的原因 依赖冲突很经常是类包之间的间接依赖引起的.每个显式声明的类包都会依赖于一些其它的隐式类包,这些隐式的类包会被maven间接引入进来,从而造成类包冲突 如何解决依赖冲突 首先查看产生依赖冲突的类jar,其次找出我们不想要的依赖类jar,手工将其排除在外就可以了.具体执行步骤如下 1.查看依赖冲突 a.通过dependency:tree是命令来检查版本冲突 mvn -Dverbose dep

一.依赖原则 假设,在 JavaMavenService2 模块中,log4j 的版本是 1.2.7,在 JavaMavenService1 模块中,它虽然继承于 JavaMavenService2 模块,但是它排除了在 JavaMavenService2 模块中继承 1.2.7 的版本,自己引入了1.2.9 的 log4j版本. 此时,相对于 WebMavenDemo 而言,log4j.1.2.7.jar 的依赖路径是 JavaMavenService1 >> JavaMavenServic

说maven依赖冲突之前需要先说说maven的 依赖传递. 依赖传递 当前项目引入了一个依赖,该依赖的依赖也会被引入项目.更加准确的说法是,maven会解析直接依赖的POM,将那些必要的间接依赖,以传递依赖的形式引入到当前项目中. 为什么说是'必要的间接依赖'呢?这是因为不是所有的间接依赖都会被引入的.这还得说说maven的 依赖范围. 依赖范围 maven引入依赖,并不是把jar包拷贝到项目中来,而是把jar包下载到本地仓库,然后通过制定classpath来在项目中引入具体的jar包.mave

这是一个Maven提高篇的系列,包含有以下文章: Maven提高篇系列之(一)——多模块 vs 继承 Maven提高篇系列之(二)——配置Plugin到某个Phase(以Selenium集成测试为例) Maven提高篇系列之(三)——使用自己的Repository(Nexus) Maven提高篇系列之(四)——使用Profile Maven提高篇系列之(五)——处理依赖冲突 Maven提高篇系列之(六)——编写自己的Plugin(本系列完) 在本系列的上一篇文章中,我们讲到了如何使用Profil

个人分类: Maven 不知道你在使用Maven时是否遇到过诸如"NoSuchMethodError"或"ClassNotFoundException"之类的问题,甚至发生这些问题的Java类你没都没有听说过.要搞清楚这里面的缘由,我们得学习Maven对依赖冲突的处理机制. Maven采用“最近获胜策略(nearest wins strategy)”的方式处理依赖冲突,即如果一个项目最终依赖于相同artifact的多个版本,在依赖树中离项目最近的那个版本将被使用.让

http://wiki.jikexueyuan.com/project/intellij-idea-tutorial/project-composition-introduce.html 在 IntelliJ IDEA 中 Project 是最顶级的级别,次级别是 Module.一个 Project 可以有多个 Module.目前主流的大型项目结构都是类似这种多 Module 结构,这类项目一般是这样划分的,比如:core Module.web Module.plugin Module.solr

举例A依赖于B及C,而B又依赖于X.Y,而C依赖于X.M,则A除引B及C的依赖包下,还会引入X,Y,M的依赖包(一般情况下了,Maven可通过<scope>等若干种方式控制传递依赖).这里有一个需要特别注意的,即B和C同时依赖于X,假设B依赖于X的1.0版本,而C依赖于X的2.0版本,A究竟依赖于X的1.0还是2.0版本呢?这就看Classloader的加载顺序了,假设Classloader先加载X_1.0,而它就不会再加载X_2.0了,如果A恰恰希望使用X_2.0呢,血案就这样不期而遇了.

为什么会出现依赖冲突 首先要说明Maven的依赖管理,具体的可以参考这边 Maven学习——依赖管理 这篇文章,maven在依赖冲管理中有一下几个原则. 依赖是使用Maven坐标来定位的,而Maven坐标主要由GAV(groupId, artifactId, version)构成.如果两个相同的依赖包,如果groupId, artifactId, version不同,那么maven也认为这两个是不同的. 依赖会传递,A依赖了B,B依赖了C,那么A的依赖中就会出现B和C. Maven对同一个gro

新版API上线后,发现LOG文件没有正常输出.查看Tomcat的Log文件发现如下的错误信息 May , :: AM com.sun.xml.ws.server.sei.EndpointMethodHandler invoke SEVERE: Found class ch.qos.logback.core.spi.CyclicBufferTracker, but interface was expected java.lang.IncompatibleClassChangeError: Foun

转载请注明原文地址:http://www.cnblogs.com/ygj0930/p/6628429.html  一:Maven依赖传递 假如有Maven项目A,项目B依赖A,项目C依赖B.那么我们可以说 C依赖A.也就是说,依赖的关系为:C—>B—>A. 那么我们执行项目C时,会自动把B.A都下载导入到C项目的jar包文件夹中. 这就是依赖的传递性. 二:依赖传递的排除 如上,C—>B—>A.加入现在不想执行C时把A下载进来,那么我们可以用 <exclusions>标