maven是一款优秀的服务构建工具，基于约定优于配置原则，提供标准的服务构建流程。maven的优点不仅限于服务构建，使用maven能够做到高效的依赖管理，并且提供有中央仓库可以完成绝大多数依赖的下载使用。
IDEA配置maven工具
File > Other Settings > Default Settings进入Default Settings设置框
Build, Execution, Deployment > Build Tools > Maven进入maven工具配置
上图中展示了三项配置，Maven home directory指向maven工具根目录，User settings file指向conf下的settings.xml文件，表示使用全局的settings.xml文件，Local repository指向本地仓库地址。
settings.xml文件
settings.xml文件起到的作用为全局作用，该文件中定义的行为一般作用于多个工程，或者所有工程。其中有几个较为重要的元素：
localRepository
本地仓库的地址，在maven工程中依赖的构件，首先到本地仓库进行查找，查找不到才会到远程仓库查找。servers
在工程中进行构件部署或者依赖下载时，添加的repositories,distributionManagement元素中定义了服务器的地址，登录服务器需要的认证信息，例如秘钥或者用户名密码需要与工程分离，所以定义在该标签中与工程进行关联。mirrors
当远程仓库的连接速度较慢时，或者使用私服进行依赖控制时，可以配置镜像服务器来替代某个或所有远程服务器。profiles
提供多套配置，根据环境不同、指定的条件判断结果，选择使用某种配置。例如在某个profile中配置远程仓库和插件仓库，根据使用的操作系统是windows或者unix，选择性激活不同的配置。activeProfiles
手动激活使用某一个profile配置。
建立maven工程
File > New > Project建立maven工程
此处填写的为项目的坐标，GroupId表示公司或组织，ArtifactId表示产品，Version表示产品版本号。
pom.xml文件
上图所示为工程根目录下的pom.xml文件内容，modelVersion表示当前POM模型的版本，对于当前的maven 3而言，元素值为4.0.0，groupId,artifactId,version则是前面提到过的工程坐标。
目录结构
由上图可知，maven默认生成的源码目录为src\main\java，默认的资源目录为src\main\resources，默认的测试目录为src\test\java。如果此工程已经完成，直接进行编译、测试等构建过程的话，则会直接到默认目录执行编译、测试活动。
以源码目录、测试目录和资源目录三种为例，可以指定源路径以及编译后目录：
<build>
<!--编译服务后的目标生成目录-->
<directory>${basedir}\target</directory>
<!--源码目录和编译后源码生成目录-->
<sourceDirectory>${basedir}\src\main\java</sourceDirectory>
<outputDirectory>${build.directory}\classes</outputDirectory>
<!--源码下资源路径和编译后资源生成路径-->
<resources>
<resource>
<directory>${basedir}\src\main\resources</directory>
<targetPath>${build.directory}\classes</targetPath>
</resource>
</resources>
<!--测试路径和编译后测试生成路径-->
<testSourceDirectory>${basedir}\src\test\java</testSourceDirectory>
<testOutputDirectory>${build.directory}\test-classes</testOutputDirectory>
</build>
<build>标签中自定义文件路径时，可以使用文件系统的全路径，也可以使用maven的内置属性进行定义。这里的${basedir}表示工程根目录，${build.directory}表示编译服务后的目标生成目录，即<directory>标签定义的目录。
服务构建
maven工程的构建过程存在三个生命周期：clean,default和site，每个生命周期存在多个阶段。clean生命周期的作用为清理工程编译后生成信息；site生命周期用于为工程生成站点，可以通过浏览器查看各项站点信息；下面主要讨论default生命周期的作用，该生命周期包含多个阶段，主要完成工作如下：
-
validate:对工程信息进行校验，判断是否缺失必要的文件 -
compile:编译源码 -
test:使用测试框架执行测试文件 -
package:对编译后文件进行打包，生成jar或war等格式文件 -
verify:对集成测试结果进行校验，判断是否达到质量标准 -
install:按照打包文件到本地仓库 -
deploy:将打包文件部署到远程服务器
之前提到过，maven的服务构建过程是通过插件来完成的，即每个阶段要执行的操作，都是通过插件定义实现的。每个插件可以定义多个goal，所以并不是每个阶段对应一个插件，而是对应插件的一个goal。通过将生命周期的阶段与插件的goal进行绑定，在使用过程中只需要声明要执行的声明周期阶段，即可调用绑定的插件goal完成操作。例如执行mvn install命令，实际执行的是install生命周期阶段绑定的插件的goal。
上图中Profiles表示使用到的配置，Lifecycle列举了常用的生命周期阶段，Plugins列举了常用插件及插件的goal，这里并没有显示出阶段与goal的绑定关系。下面展示的是maven 3.6.0版本中，打包类型为jar时，default生命周期中各阶段与插件goal的绑定关系：
<component>
<role>org.apache.maven.lifecycle.mapping.LifecycleMapping</role>
<role-hint>jar</role-hint>
<implementation>org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping</implementation>
<configuration>
<lifecycles>
<lifecycle>
<id>default</id>
<!-- START SNIPPET: jar-lifecycle -->
<phases>
<process-resources>
org.apache.maven.plugins:maven-resources-plugin:2.6:resources
</process-resources>
<compile>
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
</compile>
<process-test-resources>
org.apache.maven.plugins:maven-resources-plugin:2.6:testResources
</process-test-resources>
<test-compile>
org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile
</test-compile>
<test>
org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test
</test>
<package>
org.apache.maven.plugins:maven-jar-plugin:2.4:jar
</package>
<install>
org.apache.maven.plugins:maven-install-plugin:2.4:install
</install>
<deploy>
org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy
</deploy>
</phases>
<!-- END SNIPPET: jar-lifecycle -->
</lifecycle>
</lifecycles>
</configuration>
</component>
由绑定关系可知，执行mvn install命令时，install阶段运行的是mvn org.apache.maven.plugins:maven-install-plugin:2.4:install，该命令格式为mvn groupId:artifactId:version:goal。
多模块
以上示例展示了创建maven工程时的默认目录结构，并没有存在继承或者聚合的情况。在实际工作中，多数的项目结构较为复杂，例如工程中经常需要划分dao层、service层和web层，为了保证各层的独立性和降低各层之间的耦合度，这种情况下可以给工程建立多个模块分开管理。
右键工程，New > Module，进入模块信息窗口
新建子模块，默认继承自父模块
可以观察到父模块的pom.xml文件增加新内容
<packaging>类型自动变为pom类型，<modules>包含两个新创建的子模块。
子模块的pom.xml文件内容中，通过<parent>标签声明继承关系，继承父模块的groupId和version，所以子模块pom中只需要填写一个artifactId即可。
通过继承pom的方式，可以有效的在多模块工程中对依赖的构件进行版本控制，避免不同模块之间对同一个依赖构件的使用，存在版本不一致问题。各模块示例依赖如下：
module_A:
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.7</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.12</version>
</dependency>
</dependencies>
模块module_A依赖junit和log4j
module_B:
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.7</version>
<scope>test</scope>
</dependency>
</dependencies>
模块module_B依赖junit
当module_A和module_B都存在对同一个构件junit:junit:4.7的依赖时，可以将该构件提取到根pom文件的<dependencies>中，子模块继承根pom时会自动添加对该构件的使用。如下所示：
root:
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.7</version>
<scope>test</scope>
</dependency>
</dependencies>
在根pom中声明对构件junit:junit:4.7的依赖。
module_A:
<dependencies>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.12</version>
</dependency>
</dependencies>
模块module_A继承对junit的依赖，只需要声明log4j依赖即可。
模块module_B同样继承对junit的依赖，<dependencies>声明依赖为空，不需要该标签。
可以在根pom中配置<dependencyManagement>标签，在标签内列出子模块可能需要使用的构件及版本，当子模块使用到其中的构件时，在子模块内部声明构件的groupId和artifactId即可，以此进行版本控制。示例如下：
root:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.7</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.12</version>
</dependency>
</dependencies>
</dependencyManagement>
在根pom中列出子模块可能使用的依赖，此时并不会下载使用这些依赖。
module_A:
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</dependency>
</dependencies>
模块module_A中声明使用junit和log4j依赖，此时子模块会下载使用根pom中声明版本号的对应依赖。
module_B:
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</dependency>
</dependencies>
模块module_B中声明使用junit依赖，此时子模块会下载使用根pom中声明版本号的对应依赖。
依赖范围与依赖传递
观察之前对junit构件的依赖声明：
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.7</version>
<scope>test</scope>
</dependency>
在声明的依赖信息中，除了坐标之外，还具有scope属性，该属性即为构件的范围属性。某些scope属性指示了构件是否具有传递性。
maven依赖声明中主要有以下六种依赖范围：
compile:默认依赖范围，作用于工程的编译、测试和运行期，并且会传递到依赖该模块的工程中provided:作用于工程的编译和测试阶段，在运行期不起作用，用于表示运行期对该构件的依赖已经由容器提供，该依赖范围不具有传递性runtime:作用于测试和运行阶段，在编译期不起作用，具有传递性test:作用于测试和运行阶段，在编译期不起作用，且不具有传递性system:与provided类似，作用于工程的编译和测试阶段，在运行期不起作用，不过需要<systemPath>标签显式指明使用的是系统上的某个依赖import:只能使用于<dependencyManagement>标签中对包类型为pom的构件依赖，使用该范围后，会将依赖的pom中<dependencyManagement>标签内的依赖加载到当前<dependencyManagement>标签中。该范围对传递性没有影响
各范围传递性：
| compile | Y | Y | Y | Y |
| test | - | Y | Y | - |
| provided | Y | Y | - | - |
| runtime | - | Y | Y | Y |
若A对B依赖范围定义如左侧一列，B对C依赖范围如上面一行，则A对C的依赖性如下：
| compile | compile | - | - | runtime |
| test | test | - | - | test |
| provided | provided | - | - | provided |
| runtime | runtime | - | - | runtime |
根据表格结果可知，test、provided两个scope属性不具有传递性，所以B对C依赖范围为这两个属性值的列，A对C的依赖不存在；A对B的依赖范围为这两个属性值的行，传递过来的依赖性降低为这两个属性值。compile、runtime两个scope属性具有传递性，runtime作用范围低于compile，按照木桶原则，构件传递时按照最小范围传递，A对B的依赖范围为runtime的行，A对C的依赖性降为runtime；A对B的依赖范围为compile的行，A对C的依赖性降低为B对C的依赖性。
参考
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
https://blog.csdn.net/luanlouis/article/details/50492163
http://www.cnblogs.com/dcba1112/archive/2011/05/01/2033805.html
https://haoran-10.iteye.com/blog/2307081
本文同步分享在 博客“zhipingChen”（JianShu）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。