maven中配置 pom时,有时配置添加一个 jar却会自动导入多个 jar包,往往这些自动导入的 jar包会与我们项目中已存在的 jar包重复,从而导致冲突.由于这些 jar包不是我们自己配置的,所以遇到这种问题往往感觉一头雾水,下面记录一下开发情况中遇到的这类问题. 由于添加一个功能需要在项目中导入如下一个jar包 <dependency> <groupId>commons-httpclient</groupId> <artifactId>commons

一.前言 什么是依赖冲突 依赖冲突是指项目依赖的某一个jar包,有多个不同的版本,因而造成了包版本冲突. 依赖冲突的原因 我们在maven项目的pom中 一般会引用许许多多的dependency.例如,项目A有这样的依赖关系: A -> C -> X(1.0) B -> D -> X(2.0) X是A的传递性依赖,但是两条依赖路径上有两个版本的X,那么哪个X会被Maven解析使用呢? 两个版本都被解析显然是不对的,因为那会造成依赖重复,因此必须选择一个. 至于怎么选肯定有它的规则(

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

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

解决maven依赖冲突问题 1.idea 安装maven helper插件 2.打开pom.xml文件 底部多出一个Dependency Analyzer选项 点开这个选项 找到冲突,点击右键,选择Exclude即可排除冲突版本的jar包

​ 1.何为依赖冲突 Maven是个很好用的依赖管理工具,但是再好的东西也不是完美的.Maven的依赖机制会导致Jar包的冲突.举个例子,现在你的项目中,使用了两个Jar包,分别是A和B.现在A需要依赖另一个Jar包C,B也需要依赖C.但是A依赖的C的版本是1.0,B依赖的C的版本是2.0.这时候,Maven会将这1.0的C和2.0的C都下载到你的项目中,这样你的项目中就存在了不同版本的C,这时Maven会依据依赖路径最短优先原则,来决定使用哪个版本的Jar包,而另一个无用的Jar包则未被使用,

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

如果原始系统的jarA依赖jarB1.0 而新引入的jarC依赖jarB2.0 导致系统启动报错,提示冲突,这时为了保证原始系统的稳定性, 在pom.xml文件中引入jarC时,需要exclude掉jarB2.0 如果原始系统依赖jarA1.0 这时为了使用新的功能需要使用jarA2.0,如果子系统B中使用了jarC1.0依赖A1.0,如果在子系统B中直接使用依赖jarA2.0,肯定会 报冲突,这时需要在pom.xml修改jarC1.0的引入代码,添加exclude掉jarA1.0,然后可以添加

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

依赖冲突有两个规则: 短路优先范例:A -> B -> C -> X-2.0.0A -> D -> X-1.0.0那么A -> X-1.0.0这个版本 先声明优先范例:A -> B -> X-2.0.0A -> C -> X-1.0.0若A先声明依赖B,则A -> X-2.0.0,若A先声明依赖C,则A -> X-1.0.0

今天在用Maven集成Struts2+Spring+Hibernate时发现只要不在web模块中声明spring-web的依赖,就会报java.lang.NoClassDefFoundError: [Lorg/springframework/context/ApplicationContextInitializer;异常,站点无法启动. 对比了半天发现添加spring-web依赖后打包生成的文件少了一个spring-asm-3.0.5.RELEASE.jar文件,很是纳闷,再仔细看spring-

依赖相同的jar包,版本不一致,优先选择哪个版本呢? 1 路径短的优先 如A依赖B,B依赖C,C依赖commons.jar 1.0 A依赖D,D依赖commons.jar 2.0 那么优先解析2.0,编译的jar包为2.0 2 路径长短相同,先声明先优先解析

https://blog.csdn.net/noaman_wgs/article/details/81137893

这是一个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的多个版本,在依赖树中离项目最近的那个版本将被使用.让

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

依赖冲突:NoSuchMethodError,ClassNotFoundException   当用户应用于Spark本身依赖同一个库时可能会发生依赖冲突,导致程序奔溃.依赖冲突表现为在运行中出现NoSuchMethodError或者ClassNotFoundException的异常或者其他与类加载相关的JVM异常. 此时,若能确定classpath中存在这个包,则错误是因为classpath中存在2个不同版本的jar包了,比如常见的log4j,你在classpath中添加了log4j.jar,

使用maven的程序员都会遇到一个问题,那就是maven依赖冲突的问题,这会导致ClassNotFound或者MethodNotFound这样的异常.其实只要明白maven依赖的根本性的原则就不怕这样的问题了. 一.maven依赖原则1.间接依赖路径最短优先一个项目test依赖了a和b两个jar包.其中a-b-c1.0 , d-e-f-c1.1 .由于c1.0路径最短,所以项目test最后使用的是c1.0. 2.pom文件中申明顺序优先有人就问了如果 a-b-c1.0 , d-e-c1.1 这样

前言 我们程序员在开发的时候经常会遇到各种各样的 BUG 问题,其中大部分是业务逻辑异常,还有一些是代码书写不规范造成的异常例如:NullPointException(NPE),IndexOutOfBoundsException 等等,其实这些我们都好定位和修复.但是还有一些运行时异常定位起来是特别头疼的,那就是 jar 包冲突引起的异常. 一般程序在运行时发生类似于 java.lang.ClassNotFoundException,Method not found: '......',或者莫名

1.jar包封装完成后,其他项目引用jar,启动时报错java.lang.SecurityException: Invalid signature file digest for Manifest main attributes 这是因为jar中MATE-INF目录下存在*.SF,*.DSA,*.RSA文件,这些文件中有签名导致错误,删除即可 推荐直接在打包的时候排除掉  pom如下: <build> <plugins> <plugin> <groupId>

上篇文章中,小黑哥分析 Maven 依赖冲突分为两类: 项目同一依赖应用,存在多版本,每个版本同一个类,可能存在差异. 项目不同依赖应用,存在包名,类名完全一样的类. 第二种情况,往往是这个场景,本地/测试环境运行的都是好好的,上线之后测试就是不行. 这其实与 JVM 类加载有关,本地/测试环境加载正确类,而生产环节加载错的类,为什么会这样? 主要有两个原因: 同一个类只会被加载器加载一次 不同环境,类的加载顺序不同 同一个类只会被加载器加载一次 JVM 类加载具有缓存机制,每个类加载的时候首先