Maven生命周期、解决依赖冲突、scope

Maven生命周期

Maven 的生命周期并非只有一套，而是有三套， 并且这三套生命周期之间是没有关系的 。一套生命周期包含很多个不同的阶段，这些不同的阶段是有顺序的，有些阶段必须要在某个阶段完成之后，才能进行。Maven 的三套生命周期分别为： clean （清理）， default （默认）， site （站点）

clean

用于清理项目， clean 生命周期包括以下 3 个阶段：

1. pre-clean： 清理前的准备工作；
2. clean：清理上一次构建的结果；
3. post-clean：清理结束后需要完成的工作。

default

default 生命周期定义了项目真正构建时所需要的所有步骤，它是所有生命周期中最核心，最重要的部

分。

（这里列出了部分主要阶段）

• validate 验证项目是正确的，所有必要的信息都是可用的
• compile 编译项目源代码
• test 使用单元测试框架测试编译后的源代码
• package 获取已编译的代码，并将其打包为可发行的格式，例如JAR。
• verify 获取已编译的代码，并将其打包为可发行的格式，例如JAR。
• install 将包安装到本地仓库，供本地项目使用
• deploy 将包发布到远程仓库（remote repository），方便其他开发人员和项目共享。

site  

sit 生命周期的目的是建立和部署项目站点， Maven 能够根据 POM 包含的信息，自动生成一个友好的站

点，该站点包含一些与该项目相关的文档。

site 生命周期包含以下 4 个阶段：

1. pre-site：准备阶段。在生成站点前所需要做的工作；
2. site：生成站点阶段；
3. post-site：结束阶段。生成站点结束后所需要做的工作；
4. site-deploy：发布阶段。我们可以将上面生成的站点发布到对应服务器中。

三套生命周期本身是相互独立的，用户可以只调用 clean 生命周期的某个阶段，也可以只调用default 生命周期的某个阶段，而不会对其他生命周期造成任何影响。当然也可以同时调用两套生命周期的某个阶段。 

Maven 解决依赖冲突

这里的依赖冲突是指同一个依赖持有多个，不知道选哪个

最短路径优先原则

Maven 会根据项目中所有依赖的版本号，建立 依赖树 ，并根据最短路径原则来确定使用哪个版本。具体来说，当一个类需要一个依赖时，Maven 会检查是否有多个版本可供选择。此时， Maven 会选择距离最近的（最短路径）那个版本，并将它包含在项目中。因此，如果一个依赖发布了多个版本，而且它们有不兼容的变化，那么只有一个版本会被选择，而且它会覆盖其他版本。

版本范围控制机制

Maven 支持使用版本范围来控制依赖的版本选择。通过在依赖坐标中指定一个版本范围， Maven

将自动选择符合该范围内的版本。例如，使用 [1.0,2.0) 可以选择 1.0.0 版本及以上，但不包括 2.0.0版本。这种机制通常在项目中使用多个版本的相同的库时非常有用。例如，如果使用 JDBC 驱动程序，可能需要支持多个版本。通过使用版本范围，Maven 将选择最合适的版本，并不会出现冲突。

总之， Maven 通过最短路径优先原则和版本范围控制机制来解决依赖冲突。 Maven 不会尝试检测和解决所有的冲突，而是选择其中一个版本，并仅包含了最短路径中的那些依赖项。在依赖树中，Maven 会将路径较短的依赖视为最优先的。因此，当存在多个冲突版本时， Maven 会选择距离最近 （路径最短）的版本 ，并将其作为正式依赖加入到项目中。

scope依赖范围

1. compile，默认值，适用于所有阶段（开发、测试、部署、运行），本jar会一直存在所有阶段。
2. provided，只在开发、测试阶段使用，目的是不让Servlet容器和你本地仓库的jar包冲突 。如servlet.jar。
3. runtime，只在运行时使用，如JDBC驱动，适用运行和测试阶段。
4. test，**只在测试时使用，用于编译和运行测试代码。不会随项目发布。
5. system，类似provided，需要显式提供包含依赖的jar，Maven不会在Repository中查找它。