网站建设验收表,Wordpress搜索html页面,自动化项目外包网,如何做营销maven仲裁机制玩过springboot的人都知道 springboot项目中你一般看不到大段的spring相关包 而是像spring-boot-start一个jar包就包含spring相关的包 包含了具体版本号 #xff0c;这其实就是一个版本仲裁的结果#xff0c;不依赖程序自定义的相关包#xff0c;这样就不会造…maven仲裁机制玩过springboot的人都知道 springboot项目中你一般看不到大段的spring相关包 而是像spring-boot-start一个jar包就包含spring相关的包 包含了具体版本号 这其实就是一个版本仲裁的结果不依赖程序自定义的相关包这样就不会造成JAR冲突当前maven大行其道说到第一类Jar包冲突问题的产生原因就不得不提maven的依赖机制了。传递性依赖是Maven2.0引入的新特性让我们只需关注直接依赖的Jar包对于间接依赖的Jar包Maven会通过解析从远程仓库获取的依赖包的pom文件来隐式地将其引入这为我们开发带来了极大的便利但与此同时也带来了常见的问题——版本冲突即同一个Jar包出现了多个不同的版本针对该问题Maven也有一套仲裁机制来决定最终选用哪个版本但Maven的选择往往不一定是我们所期望的这也是产生Jar包冲突最常见的原因之一。先来看下Maven的仲裁机制优先按照依赖管理元素中指定的版本声明进行仲裁此时下面的两个原则都无效了若无版本声明则按照“短路径优先”的原则(Maven2.0)进行仲裁即选择依赖树中路径最短的版本若路径长度一致则按照“第一声明优先”的原则进行仲裁即选择POM中最先声明的版本这里的问题就产生了 按照版本仲裁的原则 比如我需要引入一个jar包 我可能会引入一个较新版本的jar包 但原来三方包里已经有这个jar低版本包 且只支持低版本 高版本还不兼容 这时 按照仲裁原则就会有问题 三方包可能出现运行时异常等问题 所以起步依赖的引入 从根本解决了这个问题
