前情提要
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对快照会维护另一个它自己生成的版本号。
依赖
<dependencies>
<dependency>
<groupId></groupId>
<artifactId></artifactId>
<version></version>
<scope></scope>、
<optional></optional>
</dependency>
</dependencies>
依赖有两个点需要注意，一是依赖的范围，二是依赖的传递性。
依赖范围 <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！所以还记得你配置插件的时候怎么写的吗？
<build>
<plugins>
<plugin>
<groupId></groupId>
<artifactId></artifactId>
<version></version>
<executions>
<execution>
<id></id>
<phase></phase>
<goals>
<goal></goal>
</goals>
<configuration></configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
在plugins标签下，申明一个插件，给定插件坐标（groupId,artifactId,version...），设置执行器，将执行器绑定到某个phase（生命周期）上，指定执行什么goal（也就是插件的动作）。如此一来，当maven经过相应任务的时候，就会使用你配置的插件中的goal。
maven不仅支持通过mvn命令行调用生命周期阶段，还支持直接调用插件的goal。我现在最常用的莫非 mvn clean spring-boot:run 。这其中的spring-boot:run,就是
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
这个插件提供的功能，这里我们直接调用了spring-boot（spring-boot-maven-plugin的name）插件的run这个goal。
maven自身提供了dependence这个插件，用来查看项目依赖，有兴趣的同学可以去查阅一下，它对于优化项目依赖有很大作用。