三.详解
1.项目对象模型pom
POM包含了四类描述和配置：
项目总体信息：它包含了一个项目的而名称，项目的URL，发起组织，以及项目的开发者贡献者列表和许可证。
构建设置：在这一部分，我们自定义Maven构建的默认行为。可以更改源码和测试代码
的位置，可以添加新的插件，将插件目标绑定到生命周期，还可以自定义站点生成参数。
构建环境：构建环境包含了一些能在不同使用环境中激活的profile。例如，开发过程中将应用部署到一个开发服务器上，而在产品环境中你会需要将应用部署到产品服务器上。
POM关系：一个项目很少孤立存在；它会依赖于其它项目，可能从父项目继承POM设置，它要定义自身的坐标，可能还会包含子模块。
maven本身超级pom位置在maven的安装目录中， ..\maven-3.0.4\lib\maven-model-builder-3.0.4.jar,\org\apache\maven\model\pom-4.0.0.xml，超级POM定义了一组被所有项目共享的默认设置，所有的POM均继承此文件。
这个超级POM定义了一些由所有项目继承的标准配置变量。对这些变量的简单解释如下：
❶ 默认的超级POM定义了一个单独的远程Maven仓库，ID为central。这是所有Maven客户端默认配置访问的中央Maven仓库。该配置可以通过一个自定义的settings.xml文件来覆盖。注意这个默认的超级POM关闭了从中央Maven仓库下载snapshot构件的功能。如果你需要使用一个snapshot仓库，你就要在你的pom.xml或者settings.xml中自定义仓库设置。
❷ 中央Maven仓库同时也包含Maven插件。默认的插件仓库就是这个中央仓库。Snapshot被关闭了，而且更新策略被设置成了“从不”，这意味着Maven将永远不会自动更新一个插件，即使新版本的插件发布了。
❸ build元素设置Maven标准目录布局中那些目录的默认值。
❹ 超级POM为核心插件提供了默认版本。这么做是为那些没有在它们POM中指定插件版本的用户提供一些稳定性
有效pom：最简单的POM能带给我们“有效POM”的概念。由于POM可以从其它POM继承配置，你就需要一直考虑超级POM，再加上任何父POM，以及最后当前项目的POM这些所有配置的结合。Maven开始于超级POM，然后使用一个或多个父POM覆盖默认配置，最后使用当前项目的POM来覆盖之前生成的配置结果。最后你得到了一个混合了各个POM配置的有效POM。
看pom真正的结构：mvn help:effective-pom 结构内容是超级POM和当前POM内容的合并。
2.pom语法
1）版本号
Maven中的版本包含：主版本，次版本，增量版本，和限定版本号。
1.2.3 代表主版本1，次版本2，增量版本3；限定版本用来标识里程碑构建：alpha和beta发布，限定版本通过连字符与主版本，次版本或增量版本隔离。例如，版本“1.2-beta-01”有一个主版本1，次版本2，和一个限定版本“beta-01”。
如果你的版本号与格式<主版本>.<次版本>.<增量版本>-<限定版本>相匹配，它就能被正确的比较；“1.2.3”将被评价成是一个比“1.0.1”更新的构件，这种比较基于主版本，次版本，和增量版本的数值。如果你的版本发布号没有符合本节介绍的标准，那么你的版本号只会根据字符串被比较；“1.0.1b”和“1.2.0b”会使用字符串比较。不要使用此种字符串形式
2）SNAPSHOT版本
发布快照版本，构建时自动再发布的包后面增加时间串。例如：mini-program-api-1.0.0-20180206.085651-7.jar。快照版本只有在开发阶段使用，上线后应发布正式版本保持稳定。
当发布一个项目的时候，你需要解析所有对SNAPSHOT版本的依赖至正式发布的版本。如果一个项目依赖于SNAPSHOT，那么这个依赖很不稳定，它随时可能变化。发布到非snapshot的Maven仓库（如http://repo1.maven.org/maven2）的构件不能依赖于任何SNAPSHOT版本，因为Maven的超级POM对于中央仓库关闭了snapshot。SNAPSHOT版本只用于开发过程。
3）项目依赖
依赖junit，并且依赖范围是test，只有在测试编译和测试运行时候才可用。
<dependency><groupId>junit</groupId><artifactId>junit</artifactId><version>3.8.1</version><scope>test</scope></dependency>
可选依赖，添加可选依赖选项optional=true时，依赖的传递性功效将失效。比如A项目中使用ehcache，并设置为可选依赖，当B项目需要依赖A项目并且也想要使用ehcache，此时需要加入A项目的依赖，同时需要加入对ehcache的依赖。
<dependency><groupId>net.sf.ehcache</groupId><artifactId>ehcache</artifactId><version>1.4.1</version><optional>true</optional></dependency>
4）依赖版本界限
不包含量词(,),包含量词 [,],在逗号前面或者后面的版本不是必须的，这种空缺意味着正无穷或者负无穷。
所谓的不包含(1.1.1,1.5.3)即 版本大于1.1.1小于1.5.3
包含[1.1.1,1.5.3]即，大于等于1.1.1小于等于1.5.3
[,1.5.3]即，小于等于1.5.3，（1.1.1，）即大于1.1.1，(1.1.1,1.5.3]即大于1.1.1，小于等于1.5.3
[1.5.3]即只有1.5.3会被使用
5）传递性依赖
一个传递性依赖就是对于一个依赖的依赖。如果project-a依赖于project-b，而后者接着依赖于project-c，那么project-c就被认为是project-a的传递性依赖。如果project-c依赖于project-d，那么project-d就也被认为是project-a的传递性依赖。Maven的部分吸引力是由于它能够管理传递性依赖，并且能够帮助开发者屏蔽掉跟踪所有编译期和运行期依赖的细节。你可以只依赖于一些包如Spring Framework，而不用担心Spring Framework的所有依赖，Maven帮你自动管理了，你不用自己去详细了解配置。
maven会自动处理依赖的冲突和重叠，自动整理出使用最新版本的依赖，但是可能会出现一些问题，此时需要手动处理，排除依赖。
6）依赖范围影响传递性依赖
最顶层一行代表了传递性依赖的范围。最左边的一列代项目对象模型表了直接依赖的范围。行与列的交叉就是为某个传递性依赖指定的范围。表中的空格意思是该传递性依赖被忽略。
如下图如果project-a包含一个对于project-b的测试范围依赖，project-b包含一个对于project-c的编译范围依赖。project-c将会是project-a的测试范围传递性依赖。
7）依赖解决
使用exclusions exclusion 排除依赖。
排除或者替换传递性依赖的情况：
1. 构建的groupId和artifactId已经更改了，而当前的项目需要一个与传递性依赖不同名称的版本——结果是classpath中出现了同样项目的两份内容。一般来说Maven会捕捉到这种冲突并且使用该项目的一个单独的版本，但是当artifactId和artifactId不一样的时候，Maven就会认为它们是两种不同的类库。
2. 某个构件没有在你的项目中被使用，而且该传递性依赖没有被标志为可选依赖。在这种情况下，你可能想要排除这种依赖，因为它不是你的系统需要的东西，你要尽量减少应用程序分发时的类库数目。
3. 一个构件已经在运行时的容器中提供了，因此不应该被包含在你的构件中。该情况的一个例子是，如果一个依赖依赖于如Servlet API的东西，并且你又要确保这样的依赖没有包含在web应用的WEB-INF/lib目录中。
4. 为了排除一个可能是多个实现的API的依赖。
8）依赖管理
使用dependencyManagement在父级pom中定义多处需要复用的依赖，并确定版本号，避免在不同项目中同一种依赖使用多个版本号造成的冲突。在子项目中直接使用父pom中的依赖并去掉版本，maven会确保该子项目像上级找到dependencyManagement中的版本。同样pluginManagement定义了多处需要服用的插件。
9）项目继承
在pom中定义parent，当一个项目声明一个parent的时候，它从父项目的POM中继承信息。它也可以覆盖父POM中的值，或者添加一些新的值。所有的Maven POM从父POM中继承值。如果一个POM没有通过parent元素指定一个直接的父项目，那这个POM就会从超级POM继承值。
mvn help:effective-pom
当你继承一个POM，你可以选择直接使用继承的POM信息，或者选择覆盖它。以下是一个Maven POM从它父POM中继承的项目列表：
• 定义符（groupId和artifactId中至少有一个必须被覆盖）
• 依赖
• 开发者和贡献者
• 插件列表
• 报告列表
• 插件执行 （id匹配的执行会被合并）
• 插件配置
Maven假设父POM在本地仓库中可用，或者在当前项目的父目录(../pom.xml) 中可用。如果两个位置都不可用，默认行为还可以通过relativePath元素被覆盖。例如，一些组织更喜欢一个平坦的项目结构，父项目的pom.xml并不在子项目的父目录中。它可能在项目的兄弟目录中。如果你的子项目在目录./project-a中，父项目在名为./a-parent的目录中，你可以使用如下的配置来指定parent-a的POM的相对位置。
10）依赖归类
如果你有一组逻辑上归类在一起的依赖。你可以创建一个打包方式为pom项目来将这些依赖归在一起，比如spring，大多数用到spring的项目，基本都会用spring的一些包，可以把这些包统一到一个pom文件，并打包成pom，在需要使用的时候，直接引入该pom。如下图
