Maven-深入理解

Maven仓库的理解，以及他们关系：

Jar包，不可能每次都要去联网下载吧，
1 本地仓储就是相当于加了一层Jar包缓存，先到这里来查，如果这里查不到，
2 就回去私服上找，如果私服也找不到，
3 就会去中央库去找，
4 找到jar后，会把jar信息同步到私服和本地仓库中

如何理解私服：
就是公司内部局域网的一台服务器，私服中存储了本公司的内部专用Jar，还充当了中央仓库的镜像，相当于一个代理！

关于的使用：
依赖管理：

可以通过这个dependency，可以很有序的在本地仓储中找到Jar包位置：

如何理解 镜像的 Snapshot 和Release 发布版本：
Maven 中仓库分为两种，snapshot快照仓库和release发布仓库。
snapshot快照仓库用于保存开发过程中的不稳定版本
release正式仓库则是用来保存稳定发行版本

定义一个组件/模块 为快照版本，只需要在pom文件中在该模块的版本号后面添加 -SNAPSHOT即可(注意这里必须是大写)

<groupId>cc.mzone</groupId>
<artifactId>m1</artifactId>
<version>0.1-SNAPSHOT</version>
<packaging>jar</packaging>

Maven会根据模块的版本号（pom文件中的version）中是否带有-SNAPSHOT 来判断是快照版本还是正式版本。

如果是快照版本，那么在mvn deploy时会自动发布到快照版本库中，会覆盖老的快照版本，在使用快照版本模块时，在不更改版本号的情况下，直接编译打包时，maven会自动从镜像服务器上下载最新的快照版本。

如果是正式发布版本，那么mvn deploy时会自动发布到正式版本库中，而使用正式版本的模块，在不更改版本号的情况下，编译打包时如果本地已经存在该版本的模块则不会主动去镜像服务器上下载。

所以在开发阶段，要将公用库的版本设置为快照版本，被依赖组件的Project 则引用快照版本进行开发，公用库的快照版本更新后，不需要修改pom文件提示版本号来下载新的版本，直接mvn执行相关编译，打包命令即可重新下载最新的快照库了

sanpshot版本：
同一个snapshot版本依赖可以多次部署（deploy）到仓库中，也就是同一个snapshot版本的依赖可以在仓库中存在多份，每一份都是代码在某一个特定时间的快照，这也是snapshot的含义。

release版本：
一个稳定的版本，是一个，不是一系列，一旦发布，永远不会改变，
但也有私服会把仓库配置成redeploy覆盖，这样release版本就伪装成snapshot。

依赖冲突解决：
传递依赖于排除依赖
传递依赖：如果我们项目引入了一个Jar包，而该Jar包有引用了其他Jar包，那么在默认情况下项目编译时，Maven会直接饮用和间接引用的Jar包都下载到本地
排除依赖：如果我们只想下载直接引用的Jar包，那么需要在pom.xml中做如下配置：将需要排除的Jar包坐标写在其中

依赖冲突
若项目中多个Jar同时引用了相同的Jar时，会产生依赖冲突，Maven采用了两种避免冲突的策略，
短路优先：

若本项目引用了A.jar，A.jar又引用了B.jar，B.jar又引用了X.jar，并且C.jar也引用了X.jar。
在此时，Maven只会引用引用路径最短的Jar。

声明优先：
若引用路径长度相同时，在pom.xml中谁先被声明，就使用谁。

聚合与继承：
聚合：
将多个项目同时运行就称为聚合

继承：
在聚合多个项目时，如果这些被聚合的项目中需要引入相同的Jar，那么可以将这些Jar写入父Pom中，各个子项目继承该pom即可。

Mavne生命周期：
compile 将Java源文件编译成class文件
test执行test目录下的测试用例
package 将项目打成Jar包 会自动制定clean+compile
clean 清楚target文件夹
install安装，将当前项目放到Maven的本地仓库中，供其他项目使用
deploy 将打包在本地仓库中的项目发布到服务器，供他人依赖使用

关于scope依赖范围：
compile ：默认scope，运行期有效，需要打入包中。
provided：编译器有效，运行期不需要提供，不会打入包中。
runtime：编译不需要，在运行期有效，需要导入包中（接口与实现分离）
test：测试需要，不会打入包中
system：非本地仓库引入，存在系统的某个路径下的jar（一般不适用）

build元素：

defaultGoal：
执行build任务时，如果没有指定目标，将使用默认值
如上，相当于执行mvn install
directory：
build目标文件的存储目录，默认情况下${basedir}/target目录
finalName：
build目标文件的名称，默认情况 如图所示

Resource配置：

resources：
一个resources元素的列表，每一个都描述与项目关联的文件是什么和在哪里
targetPath：
指定build后的resources存放的文件夹，默认是basedir
通常被打包在jar中的resources的目标路径是META_INF
filtering：
true/false ，标识这个resource，filter是否激活
directory：
定义resource文件所在的位置，默认为${basedir}/src/main/resources
includes：
指定哪些文件将被匹配，以*作为通配符
excludes：
指定哪些文件将被忽略
testResources：
定义和resource类似，只不过在test时使用

Plugins配置：

pluginManagement配置：
和plugins配置是一样的，只是用于继承，是的可以在孩子pom中使用。

则在子pom中，我们只需要配置：