【精华】maven 生命周期 + 依赖传递+ scope【依赖范围】 + 排除依赖 可选依赖

目录

一 .   lifecycle 生命周期 

二.   依赖 与 依赖传递

三.   scope 依赖范围

scope指定依赖范围

依赖传递依赖与原依赖冲突

四   maven的可选依赖与排除依赖

可选依赖   全部 

排除依赖  显式的指定

maven官网技术文档：

---

一 .   lifecycle 生命周期 

* clean：  清理项目的包

* validate：验证工程是否正确，所有需要的资源是否可用。

* compile： 编译 项目的源代码。

* test：  使用合适的单元测试框架来测试已编译的源代码。这些测试不需要已打包和布署。

* package：把已编译的代码 打包成可发布的格式，比如 jar、war 等。

（* integration-test：如有需要，将包处理和发布到一个能够进行集成测试的环境。）

* verify： 运行所有检查，验证包是否有效且达到质量标准。

* install： 把包 安装 到maven 本地仓库，可以被其他工程作为依赖来使用。

* site：  生成站点文档（报告）等。

* deploy：发布。在集成或者发布环境下执行，将最终版本的包拷到 远程repository，使得其他工程或开发者可共享

---

二.   依赖 与 依赖传递

1 间接引入的依赖.  又叫 依赖传递依赖【因为 maven的 依赖  具有传递性！ ]

       当我们引入了一个依赖的时候，就会自动引入该依赖引入的所有依赖，依次往下引入所有依赖。比如我们引入了Druid数据库连接池的SpringBoot-Starter，就自动引入了该依赖依赖的依赖。总而言之就是套娃就完事了。

 我们将这种依赖称为 间接引入的依赖.

2 直接依赖。

        在pom文件中，直接用标签中引入的依赖称为 直接依赖，

• 如果 直接依赖 和 间接引入的依赖 重复了并且版本不一样的话会怎么办呢？

  以显式的 直接依赖为主。

• 如果 间接引入的依赖冲突了 （比如maven helper里看的 conflict的s），最后引入的到底是哪个版本呢，还是说都会引入呢？

如果是间接引入的（依赖传递的）重复了，遵从以下规则：

 

简单来说，就是越在外层的优先级越高，如果同级的就按照配置顺序，配置顺序靠前的覆盖配置顺序靠后的。

---

三.   scope 依赖范围

scope指定依赖范围

首先，maven项目 如果不使用插件，依赖都不会被打包。  maven项目的依赖传递全靠pom.xml。

        scope是指依赖范围， 作用于maven的周期。指定 某包的依赖范围。（并限定 那些包  依赖传递 的范围）

编译 compile 、 测试 test、 发布后运行 deploy。

　　依赖范围   就是用来  控制依赖 和  三种classpath  (编译classpath，测试classpath、运行classpath)的关系，Maven有如下几种依赖范围： 【这里的  运行/打包deploy  和 在idea中 运行主程序main方法  不是一个概念。 】

• compile :   【默认】 编译、测试、运行 依赖范围。

        如果没有指定，就会 默认使用该依赖范围。 使用此依赖范围的Maven依赖，对于 编译、测试、运行三种 classpath都有效。典型的例子是spring-code,在编译、测试和运行的时候都需要使用该依赖。

        典型的例子是： log4j。

• test :     测试依赖范围 。   这个范围是不可传递的。

        表示应用程序的正常使用时不需要依赖项，仅适用于测试编译和执行阶段。使用次依赖范围的Maven依赖，只对于 测试classpath有效，在编译主代码或者运行项目的使用时将无法使用此依赖。典型的例子是Jnuit,它只有在编译测试代码及运行测试的时候才需要。

        典型的例子是： juint。

• provided :  只是先编译着，运行时由容器提供。 编译和测试 。   这个范围是不可传递的。

        使用此依赖范围的Maven依赖，对于 编译和测试 的classpath有效，但在运行时候无效。 表示您期望 JDK 或容器在运行时提供依赖项。

        典型的例子是： servlet-api。 编译和测试项目时需要该依赖，但在运行项目时 由容器提供，不需要重复地import。

• runtime： 有现成的不编译，在 测试和 运行时有效。

         表示编译时不需要依赖，但执行时需要依赖。Maven 在 运行时和 测试类路径中包含对此范围的依赖项，但在 编译类路径中不包含此范围。

          典型的例子是： jdbc。

依赖传递依赖与原依赖冲突

        

        如果将 依赖项（横的一行） 设置为左列中的范围，则   该依赖项的 传递依赖项（左竖列） 与顶行的范围会导致主项目中的依赖项具有交叉点列出的范围。如果没有列出范围，则意味着省略了依赖项。

1.    客（依赖项的传递依赖项）随主（当前依赖项）便   。当前项目指定下，传递依赖项只能取 两者指定范围的 交集（最小项）。
2.  有冲突时（椭圆区）保持  原则不变。  当 当前依赖项 为runtime时，但  传递依赖项  为provided， 它 不是同样不需要依赖项，反而需要编译 只是运行时由容器提供。所以仍是provided（   依赖项自己不编译；但依赖传递项  编译时需要编译，但运行时由容器提供 == 假设传递依赖项不编译， 只保留依赖传递项的 依赖关系，让容器提供==provided ）。

if  简化maven生命周期流程：

     编译（主程序） -> 测试（测试程序） -> （部署）运行, 

取值	适用范围	作用
compile	编译期、测试期、 运行期	默认 全部生命周期
test	测试期	表示正常使用时不需要。用于测试代码的编译和执行，如：junit
provided	编译期、测试期	表示先编译着，运行时由jdk等容器提供。对于 编译和测试 的classpath有效
runtime	测试期、 运行期	表示有现成的，不需要编译。测试和运行时需要。

网上说法众说纷纭，需要理解其本质，如下：

注意图中的 这个说法不太对的样子，官网上说明了 runtime包括测试类路径。如下：

---

四   maven的可选依赖与排除依赖

可选依赖   全部 

可选依赖指对外隐藏当前所依赖的资源

     junit 

     junit 

     4.12 

     true

配置了该选项之后，junit这个包里的  间接依赖/传递依赖 就失效了。

排除依赖  显式的指定

显式地指定 排除某些依赖项（多用于版本冲突的时候）。

 

     junit 

     junit 

     4.12 

      

          

             org.hamcrest 

             hamcrest-core

          

    

配置了该选项之后，指定的间接依赖/传递依赖  hamcrest-core也会失效。

 

maven官网技术文档：

Maven – Introduction to the Dependency Mechanism

Maven——依赖机制介绍