IDEA与MAVEN使用

maven是一款优秀的服务构建工具，基于约定优于配置原则，提供标准的服务构建流程。maven的优点不仅限于服务构建，使用maven能够做到高效的依赖管理，并且提供有中央仓库可以完成绝大多数依赖的下载使用。

maven自身提供有丰富的插件，可以在不使用额外插件的条件下完成服务的编译、测试、打包、部署等服务构建流程，即maven对服务的构建过程是通过多个插件完成的，且maven已经自定义了插件的行为。可以理解为每一个插件都是对接口的实现，可以自定义插件，以完成自定义功能，例如完成对不同编程语言的服务构建过程。不过相对于gradle的自定义插件行为，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文件用于记录本地仓库、远程仓库以及认证信息等maven工程使用的元素，该文件有两种级别，用户级别和全局级别，存放位置一般为${maven.home}/conf/settings.xml和${user.home}/.m2/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表示产品版本号。

使用这三个字段形成一个坐标，完成对此工程的表述。在maven的世界中，对所有依赖的引用都是通过坐标完成的，即使用GAV(GroupId,ArtifactId,Version)进行定位。

pom.xml文件

上图所示为工程根目录下的pom.xml文件内容，modelVersion表示当前POM模型的版本，对于当前的maven 3而言，元素值为4.0.0，groupId,artifactId,version则是前面提到过的工程坐标。

POM(Project Object Model)作为项目对象模型，用于描述工程信息、依赖信息，并且定义构建过程中的操作。该文件为maven构建服务流程中最重要的文件，虽然默认情况下文件内容很少，只描述了工程的坐标信息，那是因为一切构建操作都是按照约定进行执行的，即约定优于配置(Convention Over Configuration)。

目录结构

由上图可知，maven默认生成的源码目录为src\main\java，默认的资源目录为src\main\resources，默认的测试目录为src\test\java。如果此工程已经完成，直接进行编译、测试等构建过程的话，则会直接到默认目录执行编译、测试活动。

该目录结构属于约定的一种内容，因为平时建立工程目录时多按照该结构设计，所以在maven中直接生成该目录结构，避免了人工的操作。可以自定义源码和编译后目录，只需要在pom.xml文件中指定，则编译构建服务时按照指定的目录进行。

以源码目录、测试目录和资源目录三种为例，可以指定源路径以及编译后目录：

    <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工程内部存在许多可以使用的内置属性，以源码和测试为例:
${build.sourceDirectory}: 源码文件目录
${build.outputDirectory}: 源码编译后目录
${build.testSourceDirectory}: 测试文件目录
${build.testOutputDirectory}: 测试文件编译后目录

服务构建

maven工程的构建过程存在三个生命周期：clean,default和site，每个生命周期存在多个阶段。clean生命周期的作用为清理工程编译后生成信息；site生命周期用于为工程生成站点，可以通过浏览器查看各项站点信息；下面主要讨论default生命周期的作用，该生命周期包含多个阶段，主要完成工作如下：

• validate: 对工程信息进行校验，判断是否缺失必要的文件
• compile: 编译源码
• test: 使用测试框架执行测试文件
• package: 对编译后文件进行打包，生成jar或war等格式文件
• verify: 对集成测试结果进行校验，判断是否达到质量标准
• install: 按照打包文件到本地仓库
• deploy: 将打包文件部署到远程服务器

在生命周期内，对指定阶段的执行，会执行该阶段前的所有阶段，例如执行mvn test命令，实际执行的阶段有validate、compile、test。

之前提到过，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>包含两个新创建的子模块。

maven工程的默认打包类型为jar，聚合情况下的父模块打包类型默认为pom类型，因为一般父模块只存在一个pom.xml文件，不包含其他类型文件，其作用为提供根pom.xml文件给多个子模块使用。

子模块的pom.xml文件内容中，通过<parent>标签声明继承关系，继承父模块的groupId和version，所以子模块pom中只需要填写一个artifactId即可。

继承和聚合略有不同，继承关系中，被继承的pom并不知道自身被哪些工程继承，具体工程则明确知道继承哪个pom；聚合关系中，根pom中明确声明了包含哪些子模块，模块则并不感知被哪些pom包含。在该示例中，继承和聚合同时存在。

通过继承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中声明依赖，子模块自动继承依赖的方式，虽然可以统一工程中使用的构件版本号，但是当根pom中声明依赖较多时，可能会造成一些构件泛滥，即有些子模块并需要如此多的依赖。

可以在根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属性指示了构件是否具有传递性。

当工程A依赖工程B，工程B依赖工程C时，则工程A可能会加载工程B的依赖，即工程C，该情况称为依赖传递，A对B、B对C称为直接依赖，A对C称为间接依赖。

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的依赖性如下：

system与provided类似，import只做引入<dependencyManagement>标签内容的作用，对传递性没有影响，所以这两个scope属性没有列出来。

	compile	test	provided	runtime
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的依赖性。

因为存在传递依赖的情况，所以可能会存在间接依赖构件版本不一致的情况，即依赖冲突。maven选择使用的构件版本规则为 最短路径优先，若存在 A->B->C->D 2.0与A->E->D 1.0的情况，则在工程A中选择的构件D版本为1.0。若两条路径长度相同，则选择最先声明使用的构件，即 最先声明优先。

参考

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