Maven的生命周期
Maven拥有三套相互独立的生命周期，它们分别为clean，default和site。
Clean Lifecycle：
Clean Lifecycle在进行真正的构建之前进行一些清理工作。
目的是清理项目，它包含三个阶段：
pre-clean：执行一些清理前需要完成的工作。
clean：清理上一次构建生成的文件。
post-clean：执行一些清理后需要完成的工作。
Default Lifecycle：
构建的核心部分，编译，测试，打包，部署等等。
default生命周期定义了真正构件时所需要执行的所有步骤，它是生命周期中最核心的部分，它包含的阶
段如下：
- validate 验证项目是否正确和所有需要的相关资源是否可用
- initialize 初始化构建
- generate-sources
- process-sources 处理源代码
- generate-resources
- process-resources 处理项目主资源文件。对src/main/resources目录的内容进行变量替换等工作后，复制到项目输出的主classpath目录中。
- compile 编译项目的主源代码
- process-classes
- generate-test-sources
- process-test-sources 处理项目测试资源文件
- generate-test-resources
- process-test-resources 处理测试的资源文件
- test-compile 编译项目的测试代码
- process-test-classes
- test 使用单元测试框架运行测试，测试代码不会被打包或部署
- prepare-package 做好打包的准备
- package 接受编译好的代码，打包成可发布的格式
- pre-integration-test
- integration-test
- postintegration-test
- verify
- install 将包安装到Maven本地仓库，供本地其他Maven项目使用
- deploy 将最终的包复制到远程仓库，供其他开发人员和Maven项目使用
Site Lifecycle：
生成项目报告，站点，发布站点。
site生命周期的目的是建立和发布项目站点，Maven能够基于POM所包含的信息，自动生成一个友好的站点，方便团队交流和发布项目信息。该生命周期包含如下阶段：
1.pre-site 执行一些在生成项目站点之前需要完成的工作
2.site 生成项目站点文档
3.post-site 执行一些在生成项目站点之后需要完成的工作 - site-deploy 将生成的项目站点发布到服务器上
命令与生命周期关系：
每个maven命令对应生命周期的某一阶段，例如clean命令对应maven的clean阶段。test命令对应
maven的default阶段。
执行命令会自动将该阶段以前的命令执行，例如执行clean命令，将自动执行pre-clean命令。执行某个生命周期某个阶段，不会影响生命周期其他阶段。如果要执行多个生命周期的命令，中间用空格隔开。
Maven插件：
Maven本质上是一个插件框架，它的核心并不执行任何具体的构建任务，所有这些任务都交给插件来完成。例如编译源代码是由maven-compiler-plugin完成的。
每个任务对应了一个插件目标（goal），每个插件会有一个或者多个目标，例如maven-compiler-plugin的compile目标用来编译位于src/main/java/目录下的主源码，testCompile目标用来编译位于 src/test/java/目录下的测试源码。
Maven已经内置了一些常用的标准插件：
如果标准插件无法满足需求，我们还可以使用自定义插件。使用自定义插件的时候，需要声明。例如 spring-boot-maven-plugin 的会把项目所有依赖的jar包同时打包进来，形成可以直接运行的独立jar 包。
项目pom.xml文件：
依赖范围
依赖范围定义：
maven项目不同的阶段引入到classpath中的依赖是不同的。例如：编译时，maven会将与编译相关的依赖引入classpath中；测试时，maven会将测试相关的的依赖引入到classpath中；运行时，maven会将与运行相关的依赖引入classpath中；而依赖范围就是用来控制依赖于这三种classpath的关系。
在pom.xml如何配置依赖范围：
scope 标签是依赖范围的配置，值有compile（默认）、 test、 provided、 runtime、 system、import
例如junit就是在测试时使用的：
依赖范围有以下这些：
1.编译依赖范围(compile)：范围就是默认依赖范围，可以不用指定。此依赖范围对于编译、测试、运行三种classpath都有效，举个简单的例子，假如项目中有spring-core的依赖，那么spring-core不管是在编译，测试，还是运行都会被用到，因此spring-core必须是编译范围。
2. 测试依赖范围(test)：针对于测试的，使用此依赖范围的依赖，只对测试classpath有效，在编译主代码和项目运行时，都将无法使用该依赖，最典型的例子就是 Junit在测试时才需要，所以它的依赖范围是测试，因此它的依赖范围需要显示指定为test ,当然不显示指定依赖范围也不会报错，但是该依赖会被加入到编译和运行的classpath中,造成不必要的浪费 。
3. 已提供依赖范围(provided)：使用该依赖范围的依赖，只对编译和测试的classpath有效，对运行的classpath无效，典型的例子就是servlet-api，编译和测试该项目的时候需要该依赖，但是在运行时，web容器已经提供的该依赖，所以运行时就不再需要此依赖，如果不显示指定该依赖范围，并且容器依赖的版本和maven依赖的版本不一致的话，可能会引起版本冲突。
4. 运行时依赖范围(runtime)：使用该依赖范围的依赖，只对测试和运行的classpath有效，对编译的 classpath无效，典型例子就是JDBC的驱动实现，项目主代码编译的时候只需要JDK提供的JDBC接口，只有在测试和运行的时候才需要实现上述接口的具体JDBC驱动。
5. 系统依赖范围(system)：只对编译和测试的classpath有效，但是系统依赖范围必须通过配置 systemPath元素来显示指定依赖文件的路径，此类依赖不是由maven仓库解析的，而且往往与本机系统绑定，可能造成构件的不可移植，因此谨慎使用，systemPath元素可以引用环境变量。
6. 导入依赖范围(import)：该依赖范围不会对三种classpath产生影响，该依赖范围只能与 dependencyManagement元素配合使用，其功能为将目标pom文件中dependencyManagement的配置导入合并到当前pom的dependencyManagement中。有关dependencyManagement的功能请了解maven继承特性
依赖的传递性：
传递性依赖是Maven2.0的新特性。假设项目依赖于一个库，而这个库又依赖于其他库。不必自己去找出所有这些依赖，只需要加上直接依赖的库，Maven会隐式的把这些库间接依赖的库也加入到项目中。这个特性是靠解析从远程仓库中获取的依赖库的项目文件实现的。
依赖传递性与依赖范围：
依赖范围不仅可以控制依赖和三种classpath的关系，还对传递性依赖产生影响。每类依赖范围（除了import）通过不同方式影响传递性依赖，具体如下表所示。最左侧一列代表了直接依赖范围，最顶层一行代表了传递性依赖的范围，行与列的交叉单元格就表示最终的传递性依赖范围。
表中的“-“表示该传递性依赖将会被忽略
依赖排除：
如果项目X依赖于项目Y，项目Y又依赖项目Z，项目X的所有者可以使用”exclusion”元素来显式排除项目Z。
可选依赖：
如果项目Y依赖项目Z，项目Y的所有者可以使用”optional”元素来指定项目Z作为X的可选依赖。那么当项目X依赖项目Y时，X只依赖Y并不依赖Y的可选依赖Z。项目X的所有者也可以根据自己的意愿显式指定X对Z的依赖。（你可以把可选依赖理解为默认排除）。
例如B是一个持久层工具包，它支持多种数据库MySQL, PostgreSQL等，在构建这个工具包的时候，需要这两种数据库的驱动程序，但在使用这个工具包的时候，只会依赖一种数据库。项目B的依赖声明可以如下： 使用 元素指定可选依赖
Maven继承
继承的意义：
在构建多个模块的项目时候，往往会多有模块有相同的groupId、version，或者有相同的依赖，为了减少pom文件的配置、统一相同依赖的版本。可以将一个大型项目分为父工程和子工程,其中父工程的唯一作用就是定义所有子模块工程的资源版本（父工程不编写代码，只编辑pom.xml文件）
继承的实现
创建父工程：
保证父工程的pom.xml文件中定义的打包packaging标签的类型是pom。
Maven聚合
比如我们把以前controller,service,dao层全部拆分，一层是一个子项目，每一个里面都有pom文件，在构建的需要把每一个都进行构建，很麻烦。但是有了聚合，创建一个额外的模块。然后通过该模块，来构建整个项目的所有模块把他们聚合到一起，能够使用一条命令就构建多个模块。
聚合项目的pom文件举例：
