我接管了一系列年龄的系统。计划编写重建和作为一系列文章所遇到的问题。老行派遣新的分支机构，重新审视一些实用技术，并与所有人共享。[重建02]：Maven Project Jar jar包装管理机制和冲突解决方案。
在软件开发过程中，JAR软件包冲突是不可避免的。因此，如何快速定位冲突的根源并了解冲突引起的过程和基本原则是每个程序员的强制性课程。这也是提高工作效率，对访谈并在团队中脱颖而出的机会。
在实践中可以直观地感受到的JAR包装冲突性能经常具有这些：
可以直观地提出这一点，当然还有隐藏的异常情况，例如程序执行结果不符合期望。BELOW，让我们分析MAVEN项目中JAR软件包的处理机制和冲突的原因。
在Maven项目中，如果您想知道罐子冲突，则必须首先了解Maven如何管理JAR软件包。这涉及Maven的某些特征，例如依赖传输，最短路径的优先原则，以及第一个声明原则。
当在Maven项目中引入依赖项时，A的依赖项通常会引入B的JAR软件包，并且B也可能介绍C. B.在此方式的Jar package，当您在pom.xml文件中添加A依赖项时，MAVEN将自动帮助您在其中添加所有相关的依赖项。
例如，在Spring Boot项目中，当引入Spring-Boot-Starter-Web时：
目前，Maven的依赖关系可能是这样：
上述关系可以理解为依赖性。也就是说，当一个依赖关系需要另一个依赖关系时，Maven将帮助我们依次将相应的依赖性添加到项目中。
优点是使用它非常方便。您不必一个一个一个一个一个去罐子袋。缺点是会造成罐子包的冲突，我们稍后会谈论它。
链接1：它主要基于依赖性路径的长度来决定哪些依赖关系（两个冲突依赖关系）。
例如：
该项目同时在项目中引入了A和B依赖性，它们间接引入了Z依赖性，但是由于B的依赖关系链接相对较短，因此最终效果是Z（20.0）版本。这是这是最短的原理优先事项。
目前，如果Z的21.0版本与20.0版本不同，则会发生JAR软件包冲突的性能。
如果两个依赖性路径是相同的，则最短的路径优先原理不是判断。目前，需要第一个声明的第一个声明，即宣布首要任务的人。
例如：
a和b最终都取决于z。此时，B在B中首选A（POM中引入的顺序），Z（21.0）将被引入Z（21.0）的优先级。
如果Z（21.0）与Z（20.0）兼容，则JAR软件包冲突不会有任何问题。但是如果将B语句放在前面，则可能发生JAR软件包冲突。
Maven的三个原则在上面维护了罐子袋。实际上，每个原则都会发生什么样的JAR软件包冲突。这是另一个全面的例子。
例如：
假设根据依赖性传输机制和默认依赖依赖关系，同时在项目中引入了A和D的依赖项（首先：该方法的路径是首选；第二：首选），首选），默认情况下将引入G20版本的JAR软件包，并将引入G21，并将引入G21，并将引入G21，并将引入G21，并将引入G21，并将G21引入G21，G21。将被引入，并将引入G21。不会引用JAR包。
如果C中的方法使用G21版本中的新方法（或类），则由于Maven的处理，未引入G21。这次，该程序在调用相应的类时会引发异常，相应的方法将被扔出去。
在该想法的高版本中，maven取决于管理插件，并依次执行：打开pom.xml文件，右键单击文件中，选择maven，选择maven，选择显示依赖项以查看Maven的依赖性层次结构：
执行后显示的效果是Spring-Boot-Web的初始效果。在图中，您可以清楚地看到您使用的依赖项，其级别，是否有冲突罐袋等。冲突部分将用红色标记，默认情况下由Maven选择哪个版本。
如果您的想法版本中没有Maven Management插件 - 也可以安装Maven助手。此插件可帮助您分析JAR软件包冲突。
安装插件-in后，重新启动后，打开pom.xml文件，您可以在文件下方的“依赖项分析仪”视图中查看JAR软件包冲突的结果分析：
目前，关于哪种罐子袋的冲突。在同一时间，您可以正确单击冲突罐包并执行“排除”以消除它。在pom.xml中，将自动添加排除JAR软件包的属性。
对于本地环境，您可以使用插头 - 诸如Maven Helper之类的插头来解决它，但是它在预生产或生成环境中并不那么方便。这次，您可以通过命令找到出色的详细信息。
执行以下命令：
注意不要省略，否则不会显示忽略的软件包。
执行结果如下：
通过此形式，您还可以清楚地看到哪些JAR软件包有冲突。
如上面的屏幕截图所示，如果一个项目具有n个多个子项目，则可能不可避免地会有项目之间的关系，而JAR软件包冲突是不可避免的。目前，父型POM可用于统一管理版本。
通常，该方法是尽可能多地在父模块的POM文件中声明，然后简单地在Sub -Pom中引用（不再指定版本）。
例如，在父亲pom.xml中定义伦波克版：
您可以在子模块中定义以下内容：
这样，所有子模块都使用统一版本。
以下是根据Maven项目解决JAR冲突的方法：
上面提到了项目中的JAR包冲突的原理和解决方案以及实际战斗级别的解决方案，但它不涉及JAR软件包冲突的性质。Jar Pack冲突的本质已在详细说明文章“从JAR软件包的冲突到类加载机制。在这里，我们将在此处概述几个关键点。
JAR软件包冲突的本质：Java应用程序与期望不一致，因为某些因素没有加载正确的类。
有两种具体情况：
第一个也是专注于本文的场景，这意味着已经引入了许多罐装袋。不同的罐装袋有不同的类别和方法。由于Maven依赖于树木的仲裁机制，因此Maven加载了错误的JAR包，这导致了Jar套件的冲突；
情况第二，同一类别出现在不同的罐装袋中（在上一篇文章中，详细描述）。这种情况是，JVM的同一类加载程序只有一旦同一类才能加载。现在，加载了一堂课后，将不会加载带有完整名称的课程，这将导致JAR软件包冲突。
对于第二种情况，如果不是冲突的异常，您可能根本不知道它，因此它将变得更加棘手。在这种情况下，您可以将上一篇文章中描述的偏好用于调整不同类型的加载程序和加载路径的优先级，以及要调整的文件系统的文件加载顺序以解决该系统。
除上述方法外，还有许多提示可以检查课程。例如，IDE提供的搜索功能直接搜索异常类，以查看是否有多个，是否按预期版本使用，等等。需要在实践过程中连续探索和积累这些技术。
简而言之，无论该项目有多大以及依赖性多么复杂，只要您牢记冲突的原因以及解决冲突的方式，您都将始终遵循。阅读本文，练习，练习，您可能在团队中脱颖而出，成为Jar Pack冲突的终结者。
博客作者简介：“ Springboot Technology Inner Book”技术书籍作者，喜欢学习技术，撰写技术干货文章。
公共帐户：计划新愿景