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

举例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呢,血案就这样不期而遇了.

我自己遇到了一个问题: 我需要使用一个api,这个api已经引入包:slf4j-log4j12 所以,在自己的pom中,如果引入了这个包,需要exclude掉: 因为在pom.xml中查询是找不到的, 所以使用了 mvn dependency:tree; 就显示出来了:发现slf4j-log4j12 在包:com.sankuai.sc.yue 里面,直接exclude 就行了: slf4j-log4j12

1:前言 做软件开发这几年遇到了许多的问题,也总结了一些问题的解决之道,之后慢慢的再遇到的都是一些重复性的问题了,当然,还有一些自己没有完全弄明白的问题.如果做的事情是重复的,遇到重复性问题的概率也就会比较多了,如果是在一个新的领域里玩,遇到的问题又都是新的,自己从来没有见过的,但是问题的解决思路基本是类似的.下面这个问题,我觉得值得一记,因为以后还会再遇到类似的,我希望自己能很快的将其解决掉. 2:报错信息 如下是更新项目后,启动项目时抛出的部分错误信息. 十二月 14, 2016 7:52:

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是检查版本

今日思语:人生方方长长,努力把她磨成方圆,所以 加油咯~ 使用maven可以很方便的进行项目依赖的管理,即可以管理我们显示引入具体版本的依赖,也可以管理某些第三方引入的一些依赖的版本,从而能更好的实现摸一个依赖在整个项目中只存在唯一一个版本(使用dependencyManagement元素进行管理),示例效果如下: 没统一管理前: A模块: B模块: 父级pom统一管理后,即使用dependencyManagement元素进行管理 统一管理后各子模块的对应依赖版本 A模块: B模块: 这里就是对

调节原则 1 路径近者优先原则 自己添加一个想要依赖的版本 2第一声明者优先原则 谁排在前面就用谁的 以上两种统称为 调节原则 排除原则 排除自己的不想要的版本 版本锁定 谁能够提供锁定的版本,就用谁的 版本变量提取

女朋友他们项目用了 spring-boot,以 spring-boot-parent 作为 parent: <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.0.9</version> </parent> 女朋友最近想用 elast

参考:官方文档 - Build System of Maven https://blog.didispace.com/books/spring-boot-reference/IX. 'How-to' guides/80.3 Customize dependency versions.html 对于 SpringBoot 使用 Maven 构建项目做依赖管理大致分下面两种情况,一种是以 spring-boot-starter-parent 作为父模块,属于默认的方式:另一种是不用 Parent P

maven 重复依赖不同版本 选择规则 本篇主要来看看 maven 对于 重复依赖的jar的不同版本时候 它内部的选择规则, 很多时候我们在搭建环境的时候 不注意就会存在依赖冲突等问题 那依赖冲突的时候 为什么maven选择了不是你如你所想的jar 版本呢 , 其实都是有一定规则的 下面来看看吧 1.前言 我们在使用maven 的时候 多多少少遇到过jar包冲突的问题, 在对一个jar包引入不同版本后,可能会导致NoSuchMethodError 错误, 那么你真的清楚 maven 在多个版本j

1查询官网地址,提供了详细的各个版本的jar依赖版本信息 https://www.cloudera.com/documentation/enterprise/release-notes/topics/cdh_vd_cdh5_maven_repo_516x.html

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

1.Maven的依赖1.1 添加依赖1.2 依赖范围(sope)依赖范围与classpath的关系1.3 依赖的传递性1.2.1 依赖传递性的冲突问题1. 第一种情况2. 第二种情况1.2.2 通过exclusions元素排除不想要的传递性依赖1.2.3 依赖传递性冲突问题解决办法总结1.4 依赖版本的界限 1.Maven的依赖 Maven的依赖通过dependencis元素来配置依赖,这是Maven最强大的特性之一.它支持传递性依赖. 1.1 添加依赖 在Maven中需要使用在dependen

若排版紊乱可查看我的个人博客原文地址 maven的依赖特性很多很杂,这里大概总结一下,maven的依赖特性主要是依赖范围和传递依赖,前者会影响后者,这篇文章会介绍传递依赖的传递原则,出现冲突传递依赖默认如何处理,我们自己可以怎么处理等内容 依赖范围 依赖范围会影响传递性依赖,同时也会影响项目构建任务中使用的classpath. Maven有以下6种依赖范围: compile 这是默认范围.如果没有指定,就会使用该依赖范围.编译依赖对项目所有的classpath都可用.此外,编译依赖会传递到依赖的

今天Maven添加依赖时候发现json lib这个包引入之后,死活出不来JSONObject这个类,打开Maven Project视图,发现json-lib这个包没下下来,以前也遇到过类似问题,都是网络原因没下载成功,反复了几次都没能下成功. 以前也遇到过类似问题,都是通过下载jar包 安装到本地仓库的方式解决的,下载json-lib的jar.  我都是在中央仓库找到对应版本jar下载下来:https://mvnrepository.com/ 点击上面的 红色箭头指向的jar就可以下载, 不知道

依赖: <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.0</version> <scope>test</scope> </dependency>1.依赖的范围(依赖的有效性) compile(默认值) test 比如:Junit provided 比如:servlet-api

我们知道dependencies是可以被继承的,这个时候我们就想到让我们的发生了共用的依赖元素转移到parent中,这样我们又进一步的优化了配置.可是问题也随之而来,如果有一天我创建了一个新的模块,但是这个模块不需要这些parent的依赖,这时候如何处理? 是的,maven的依赖管理就是来解决这个问题的 增加一个新的元素:dependencyManagement 从上面的列表中我们发现dependencyManagement也是可以被继承的,这恰恰满足了我们的需要,它既能够让子模块继承到父模块的

创建Spring Boot操作步骤如下: 在File菜单里面选择 New > Project,然后选择Spring Initializr 更换版本 或 pom spring-boot-starter-parent是一个特殊的starter,它用来提供相关的Maven默认依赖,使用它之后,常用的包依赖可以省去version标签 如果你不想使用某个依赖默认的版本,您还可以通过覆盖自己的项目中的属性来覆盖各个依赖项,例如,要升级到另一个Spring Data版本系列,您可以将以下内容添加到pom.xm

问题 maven传递依赖 解决方案   前段时间,开发中遇到一个关于maven依赖包的问题:由于业务需要,支付网关对账代码中的slf4j-api包需要更新,原包为1.5.8版本,需要更新到1.6.4版本.如下图:   本来应该是件很简单的事情,把pom.xml文件里的依赖项修改下就OK了嘛!可是,打开pom.xml文件才发现,dependency里根本没有slf4j的配置信息.那么,问题来了,这个jar包是怎么引进来的呢?研究了半天也没找到根源,由于还有其他工作,就没有继续研究,临时解决方案为:

1. Snapshot版本代表不稳定.尚处于开发中的版本 2. Release版本则代表稳定的版本 3. 什么情况下该用SNAPSHOT? 协同开发时,如果A依赖构件B,由于B会更新,B应该使用SNAPSHOT来标识自己.这种做法的必要性可以反证如下: a.如果B不用SNAPSHOT,而是每次更新后都使用一个稳定的版本,那版本号就会升得太快,每天一升甚至每个小时一升,这就是对版本号的滥用. b.如果B不用SNAPSHOT, 但一直使用一个单一的Release版本号,那当B更新后,A可能并不会接受

什么是Maven 1 依赖的管理:仅仅通过jar包的几个属性,就能确定唯一的jar包,在指定的文件pom.xml中,只要写入这些依赖属性,就会自动下载并管理jar包. 2 项目的构建:内置很多的插件与生命周期,支持多种任务,比如校验.编译.测试.打包.部署.发布... 3 项目的知识管理:管理项目相关的其他内容,比如开发者信息,版本等等 官网:http://maven.apache.org/ Maven库:http://repo2.maven.org/maven2/ 中央仓库资源:http://