依赖归类
org.spring.framework spring-core ${spring.version} org.spring.framework spring-beans ${spring.version} org.spring.framework spring-web ${spring.version} org.spring.framework spring-mock ${spring.version} 2.5
多模块 & 继承
在Maven的多模块工程中，都存在一个pom类型的工程作为根模块，该工程只包含一个pom.xml文件，在该文件中以模块（module）的形式声明它所包含的子模块，即多模块工程。
在子模块的pom.xml文件中，又以parent的形式声明其所属的父模块，即继承。
多模块的好处是你只需在根模块中执行Maven命令，Maven会分别在各个子模块中执行该命令，执行顺序通过Maven的Reactor机制决定。
1）如果保留webapp和core中对maven-multi-module的父关系声明，即保留 “
（2）如果保留maven-multi-module中的子模块声明，而删除webapp和core中对maven-multi-module的父关系声明，又会出现什么情况呢？此时整个工程只是一个多模块工程，而没有父子关系。Maven会正确处理模块之间的依赖关系，即在webapp模块上执行Maven命令之前，会先在core模块上执行该命令，但是由于core和webapp模块不再继承自maven-multi-module，对于每一个依赖，他们都需要自己声明，比如我们需要分别在webapp和core的pom.xml文件中声明对Junit依赖。
依赖范围（scope）
引入依赖范围的原因示例：
1 例如Junit，将Junit的jar包打包到发布包是没有必要的。
2 例如servlet-api，为了编译通过，我们引入servlet-api jar包；但因为web容器也会提供servlet-api，如果将servlet-api打包至WAR包，就会造成依赖冲突。
示例：
junit junit 4.4 test javax.servlet servlet-api 3.1 provided
scope详解：
1 complie
默认值。参与当前项目的编译，后续的测试，运行，是一个比较强的依赖。
2 test
参与包括测试代码的编译，执行。比较典型的如junit。
3 runtime
被依赖项目无需参与项目的编译，不过后期的测试和运行周期需要其参与。
与compile相比，跳过编译而已.
oracle jdbc驱动架包就是一个很好的例子，一般scope为runntime。另外runntime的依赖通常和optional搭配使用，optional为true。我可以用A实现，也可以用B实现。
4 provided
打包的时候不包进去，别的设施(如Web Container)会提供。
事实上该依赖理论上可以参与编译，测试，运行等周期。
相当于compile，但是在打包阶段做了exclude的动作。
5 system
从参与度来说，也provided相同，不过被依赖项不会从maven仓库抓，而是从本地文件系统拿，一定需要配合systemPath属性使用。
| 依赖范围（scope） | 主源码classpath可用 | 测试源码classpath可用 | 会被打包 |
| compile 缺省值 | TRUE | TRUE | TRUE |
| test | FALSE | TRUE | FALSE |
| runtime | FALSE | TRUE | TRUE |
| provided | TRUE（外界提供） | TRUE | FALSE |
scope的依赖传递
A–>B–>C。当前项目为A，A依赖于B，B依赖于C。知道B在A项目中的scope，那么怎么知道C在A中的scope呢？答案是：
当C是test或者provided时，C直接被丢弃，A不依赖C；
否则A依赖C，C的scope继承于B的scope。
下面是一张nexus画的图。
分类器（classifer）
GAV是Maven坐标最基本最重要的组成部分，但GAV不是全部。
还有一个元素叫做分类器（classifier），90%的情况你不会用到它，但有些时候，分类器非常不可或缺。
举个简单的例子，当我们需要依赖TestNG的时候，简单的声明GAV会出错，因为TestNG强制需要你提供分类器，以区别jdk14和jdk15，我们需要这样声明对TestNG的依赖：
org.testng testng 5.7 jdk15
你会注意到maven下载了一个名为testng-5.7-jdk15.jar的文件。
其命名模式实际上是
理解了这个模式以后，你就会发现很多文件其实都是默认构件的分类器扩展，如 myapp-1.0-test.jar, myapp-1.0-sources.jar。
分类器还有一个非常有用的用途是：我们可以用它来声明对test构件的依赖，比如，我们在一个核心模块的src/test/java中声明了一些基础类，然后我们发现这些测试基础类对于很多其它模块的测试类都有用。没有分类器，我们是没有办法去依赖src/test/java中的内容的，因为这些内容不会被打包到主构件中，它们单独的被打包成一个模式为
我们可以使用分类器来依赖这样的test构件：理解了分类器，那么可供依赖的资源就变得更加丰富。
org.myorg.myapp core ${project.version} test
依赖管理（dependencyManagement）
实际的项目中，你会有一大把的Maven模块，而且你往往发现这些模块有很多依赖是完全项目的，A模块有个对spring的依赖，B模块也有，它们的依赖配置一模一样，同样的groupId, artifactId, version，或者还有exclusions, classifer。
细心的分会发现这是一种重复，重复就意味着潜在的问题，Maven提供的dependencyManagement就是用来消除这种重复的。
正确的做法是：
1. 在父模块中使用dependencyManagement配置依赖
2. 在子模块中使用dependencies添加依赖
dependencyManagement实际上不会真正引入任何依赖，dependencies才会。但是，当父模块中配置了某个依赖之后，子模块只需使用简单groupId和artifactId就能自动继承相应的父模块依赖配置。
依赖配置越复杂，依赖管理所起到的作用就越大，它不仅能够帮助你简化配置，它还能够帮你巩固依赖配置，也就是说，在整个项目中，对于某个构件（如mysql）的依赖配置只有一种，这样就能避免引入不同版本的依赖，避免依赖冲突。
示例：
父模块：
4.0.0 org.sonatype.mavenbook a-parent 1.0.0 ...... mysql mysql-connector-java 5.1.2
子模块：
4.0.0 org.sonatype.mavenbook a-parent 1.0.0 project-a ...mysql mysql-connector-java
传递依赖 & 依赖冲突
依赖冲突时，Maven采用“最近获胜策略（nearest wins strategy）”。
如果一个项目最终依赖于相同artifact的多个版本，在依赖树中离项目最近的那个版本将被使用。
示例：
github源代码：https://github.com/davenkin/maven-dependency-conflict-demo
resolve-web项目的依赖关系如下：
根据Maven的transitive依赖机制，resolve-web将同时依赖于project-common的1.0和2.0版本，这就造成了依赖冲突。而根据最近获胜策略，Maven将选择project-common的1.0版本作为最终的依赖。
在resolve-web中执行"mvn dependency:tree -Dverbose"可以看到resolve-web的依赖关系：
[INFO] resolve-web:resolve-web:war:1.0-SNAPSHOT [INFO] +- junit:junit:jar:3.8.1:test [INFO] +- project-B:project-B:jar:1.0:compile [INFO] | \- project-C:project-C:jar:1.0:compile [INFO] | \- (project-common:project-commmon:jar:2.0:compile - omitted for conflict with 1.0) [INFO] +- project-A:project-A:jar:1.0:compile [INFO] | \- project-common:project-commmon:jar:1.0:compile [INFO] \- javax.servlet:servlet-api:jar:2.4:provided
由上可知，project-common:project-commmon:jar:2.0被忽略掉了。此时在resolve-web的war包中将只包含project-common的1.0版本，于是问题来了。由于project-common的1.0版本中不包含sayGoodBye()方法，而该方法正是project-C所需要的，所以运行时将出现“NoSuchMethodError”。
对于这种有依赖冲突所导致的问题，我们有两种解决方法。
方法1：显式加入对project-common 2.0版本的依赖。先前的2.0版本不是离resolve-web远了点吗，那我们就直接将它作为resolve-web的依赖，这不就比1.0版本离resolve-web还近吗？在resove-web的pom.xml文件中直接加上对project-common 2.0 的依赖：
project-common project-commmon 2.0
方法2：resolve-web对project-A的dependency声明中，将project-common排除掉。在resolve-web的pom.xml文件中修改对project-A的dependency声明：
project-A project-A 1.0 project-common project-commmon
方法3：另外，我们还可以在project-A中将对project-common的依赖声明为optional，optional即表示非transitive，此时当在resolve-web中引用project-A时，Maven并不会将project-common作为transitive依赖自动加入，除非有别的项目（比如project-B）声明了对project-common的transitive依赖或者我们在resolve-web中显式声明对project-common的依赖（方法一）。
Profile
Maven的Profile用于在不同的环境下应用不同的配置。一套配置即称为一个Profile。
Maven提供了Activation机制来激活某个Profile，它既允许自动激活（即在某些条件满足时自动使某个Profile生效），也可以手动激活。
Profile可配置“
apple true APPLE banana BANANA
为了打印出fruit这个属性，我们再向pom.xml中添加一个maven-antrun-plugin插件，我们可以通过该插件的echo任务来打印属性信息。我们将该打印配置在Maven的initialize阶段（任何阶段都可以）：
maven-antrun-plugin initialize run Fruit:${fruit}
配置完成之后，执行：“mvn initialize”，由于id为apple的Profile默认生效，此时将在终端输出“APPLE”字样：
......
[INFO] Executing tasks
[echo] Fruit:APPLE
[INFO] Executed tasks
......
如果要使用id为banana的Profile，我们可以显式地指定使用该Profile："mvn initialize -Pbanana"
私服（Repository）
Maven提高篇系列之（三）——使用自己的Repository(Nexus)
Plugin
Maven就其本身来说只是提供一个执行环境，它并不知道需要在项目上完成什么操作，真正操作项目的是插件（plugin）。
比如编译Java有Compiler插件，打包有Jar插件等。
所以要让Maven完成各种各样的任务，我们需要配置不同的插件，甚至自己编写插件。
参考资料：
Maven提高篇系列之（一）——多模块 vs 继承
Maven提高篇系列之（三）——使用自己的Repository(Nexus)
Maven提高篇系列之（四）——使用Profile
Maven提高篇系列之（五）——处理依赖冲突
Maven提高篇系列之（六）——编写自己的Plugin
Maven依赖中的scope详解
Maven最佳实践：管理依赖