前情提要
maven这个工具用了好久了，但是一直都用的迷迷糊糊的，没有对它进行过系统性的学习，只是知道一些常用的功能怎么实现，所以20190516这一天我从JD购买了徐晓斌老师所著的《maven实战》一书，准备系统性的学习一下maven。
pom结构
我工作的主力语言是java，spring框架这个体系，所以pom文件天天见。
该文件下，有用来声明当前项目坐标的<groupId>,<artifactId>,<name>,<version>这几个字段。还有用来声明依赖的<dependencies>。以及用来声明插件的<build>。
坐标
maven使用由<groupId>,<artifactId>,<version>构成的坐标来唯一确认一个构件（任何类型的maven项目都可被理解为构件）。既然是坐标，那么<groupId>,<artifactId>,<version>的指向就具有唯一性。<version>的命名有有无“-SNAPSHOT”的区别，如果在版本后加了“-SNAPSHOT”，则表示该版本是一个快照版，是不稳定的。快照版有它独特的用处：当你依赖了一个快照版的构件时，maven会在打包时去检查本地仓库中该快照的最新代码（maven默认会每天和远程仓库同步一次数据，这是可以配置的，具体请查阅书籍或者文档），例如，B构件依赖了A构件的“0.1-SNAPSHOT”版本，我给A添加了一些代码，并在仓库重新deploy了一次A的“0.1-SNAPSHOT”。此时你重新构建B，A的“0.1-SNAPSHOT”的新代码就已经被包含进去了。如果没有“-SNAPSHOT”的帮助，B要想使用A的新特性，A需要以新的版本号发布，B需要修改pom去依赖新版本的A，本质上是A提供了新版本坐标，B去依赖新版本。而快照版则是，AB都不修改坐标，但B能使用A的新代码。至于maven是怎么实现的，大家想知道就去看书吧，我就不赘述了，大概就是maven对快照会维护另一个它自己生成的版本号。
依赖
、
依赖有两个点需要注意，一是依赖的范围，二是依赖的传递性。
依赖范围 <scope>
依赖范围有6：compile,test,provided,runtime,system,import
在介绍这几个范围之前，还需要介绍一个叫做classpath的概念，我个人理解它是编译环境的意思，我没深究。maven有3套classpath，一是编译classpath，二是测试classpath，三是运行时classpath。依赖范围会决定一个构件是否被纳入某个classpath。比如，junit依赖范围选则test，则运行时classpath就不会包含junit包。
编译环境对各个依赖范围的关系是： compile表示进入所有classpath。test表示只进入测试classpath。provided表示进入编译和测试classpath。runtime表示进入运行时和测试classpath。system和provided一致（但system需要多一个<systemPath>参数标签做配合，它是用来引入非maven仓库包的）。inport比较特殊，是用来支撑maven聚合与继承特性的，它和依赖范围没关系，后文再介绍。
默认是compile范围，常见的情况就是给一个test范围，表示只在测试classpath有效，这样在最后的打包文件中，就不会把一些用来测试的包也收录进去，节省空间。
依赖传递性
假如：A依赖B，B依赖C。
从A的角度来说，A对B是第一直接依赖，A对C是传递性依赖，B对C是第二直接依赖。
- 当第二直接依赖是compile时，传递性依赖的范围和第一直接依赖范围一致。（如C是B的compile依赖，则B是A的什么范围依赖，C就是A的什么范围依赖）。
- 当第二直接依赖是test时，依赖不会传递。
- 当第二直接依赖是provided时，只在第一直接依赖为provided时传递，并也是以provided范围传递的。（如c->b=provided,b->a=provided,c->a=provided）
- 当第二直接依赖是runtime的时候，传递性依赖与第一直接依赖的范围一致，除了compile，它会被传递为runtime。（如c->b=runtime,b->a=compile,c->a=runtime。如c->b=runtime,b->a=test,c->a=test）
最后，有一个叫做<optional>的选项，当它被设置为true时，整个依赖不会被传递。对A来说，看起来就像B没有依赖C一样。此时，A要成功编译，它得自己添加一个C依赖。这个功能是用来解决某些接口有多种实现的场景。到需要的时候大家去查阅书籍吧。此时只要知道有这么个功能就行。
插件
maven归根到底是个编译工具，maven将编译任务拆成了一堆特定的任务，这些任务就组成了maven的生命周期。
三大任务：clean，default，site
-
clean中的子任务
-
pre-clean
-
clean
-
post-clean
-
-
default中的子任务
-
validate
-
initialize
-
generate-sources
-
process-sources
-
generate-resources
-
process-resources
-
compile
-
process-classes
-
generate-test-sources
-
process-test-sources
-
generate-test-resources
-
process-test-resources
-
test-compile
-
process-test-classes
-
test
-
prepare-package
-
pachage
-
pre-integration-test
-
integration-test
-
post-integration-test
-
verify
-
install
-
deploy
-
-
site中的子任务
-
pre-site
-
site
-
post-site
-
site-deploy
-
上面列举的任务是按照maven执行的顺序罗列的。 maven给其中的某几个子任务绑定了默认的执行器，包括clean，compile，test，pachage，install，deloy等，所以拿到maven后你什么都不配置，也能执行mvn clean，mvn install 这样的命令。这些任务的功能我没有记，不过只需要知道大概有这么个体系就行，什么时候需要了，什么时候再去查阅书籍就可以。
看到这些任务，你有没有一种似曾相识的感觉，反正我看到这些任务的时候，顿时就明白，命令行上输入的mvn clean install是什么了，很亲切。实际上，但你在命令行执行mvn指令的时候，就是告诉maven，去执行哪个子任务，而由于任务有先后顺序，所以maven会从第一个任务开始执行，直到你指定的任务为止。而clean，default，site这三个大任务是各自独立的。mvn clean install表示：执行clean任务中的clean子任务，和default任务中的install任务。所以mvn clean install的完整写法其实是：mvn clean:clean default:install。于是maven会从pre-clean执行到clean，以及从validate执行到install。
认识了任务（也就是maven的生命周期），我们就可以认识插件了。maven插件有一个概念叫：goal，也就是目标。这个goal可以理解为是一个方法，用来执行一些逻辑。maven会根据你的配置，把插件的goal绑定到任务上，这个任务在maven中叫做phase！所以还记得你配置插件的时候怎么写的吗？
在plugins标签下，申明一个插件，给定插件坐标（groupId,artifactId,version...），设置执行器，将执行器绑定到某个phase（生命周期）上，指定执行什么goal（也就是插件的动作）。如此一来，当maven经过相应任务的时候，就会使用你配置的插件中的goal。
maven不仅支持通过mvn命令行调用生命周期阶段，还支持直接调用插件的goal。我现在最常用的莫非 mvn clean spring-boot:run 。这其中的spring-boot:run,就是
org.springframework.boot spring-boot-maven-plugin
这个插件提供的功能，这里我们直接调用了spring-boot（spring-boot-maven-plugin的name）插件的run这个goal。
maven自身提供了dependence这个插件，用来查看项目依赖，有兴趣的同学可以去查阅一下，它对于优化项目依赖有很大作用。
maven属性
maven允许你在pom文件中使用"${}"语法来引用属性，那么maven提供了哪些属性，我们如何自己声明属性，就是需要学习的。此处不需要记住，需要时回头来看这部分的总结就可以了。
maven一共提供了6类属性，分别如下：
-
内置属性
内置属性主要有常用的两个
-
${basedir}
表示项目的根目录，也就是包含pom文件的那个目录
-
${version}
表示项目版本
-
-
POM属性
这些属性和POM元素对应，其中一些具有默认值，默认值已在超级POM中定义好了。常见的如下。
-
${project.build.sourceDirectory}
项目的源码目录：src/main/java/
-
${project.build.testSourceDirectory}
项目的测试源码目录：src/test/java/
-
${project.build.directory}
项目构建输出目录：target/
-
${project.outputDirectory}
项目源码编译输出目录：target/classes/
-
${project.testOutputDirectory}
项目测试源码编译输出目录：target/test-classes/
-
${project.groupId}，${project.artifactId}，${project.version}
项目坐标
-
${project.build.finalName}
项目打包后的文件名，默认：${project.artifactId}-${project.version}
-
-
自定义属性
在POM的<properties>元素下自定义的maven属性，在其他地方用
${xxx}形式使用，maven会自动替换。 -
Settings属性
原理和POM属性相似，只不过Settings属性需要用户使用
${settings.xxx}的形式，来引用settings.xml文件中的XML元素属性。常用的有-
${settings.localRepository}
用户本地仓库的地址
-
-
Java系统属性
所有java系统属性，maven都可以引用，详细信息可通过
mvn help:system指令查看。 -
环境变量属性
所有环境变量，maven都可通过
${env.xxx}的形式引用。
资源过滤
maven的属性不仅在POM中可以引用，在其他资源文件中也可以引用，只需要设定过滤器就可以。我以spring-boot项目为例，spring-boot项目需要通过<parent>标签设定一个spring boot starter为父工程。如：
org.springframework.boot spring-boot-starter-parent 1.5.21.RELEASE
打开这个父工程的pom你会发现有这样一段配置
${basedir}/src/main/resources true **/application*.yml **/application*.yaml **/application*.properties ${basedir}/src/main/resources **/application*.yml **/application*.yaml **/application*.properties
原理是，maven使用插件maven-resources-plugin来将项目的资源文件复制到编译输出文件夹下去，通过在<build>标签下申明<resources><resource>标签，你可以改变插件maven-resources-plugin的行为。可以看到，spring boot starter的配置启动了filter去过滤形如**/application*.yml的文件，过滤器会将资源文件中的${xxx}自动替换为pom属性。