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.xmlLocal 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.0groupId,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,defaultsite,每个生命周期存在多个阶段。clean生命周期的作用为清理工程编译后生成信息;site生命周期用于为工程生成站点,可以通过浏览器查看各项站点信息;下面主要讨论default生命周期的作用,该生命周期包含多个阶段,主要完成工作如下:

  • validate: 对工程信息进行校验,判断是否缺失必要的文件
  • compile: 编译源码
  • test: 使用测试框架执行测试文件
  • package: 对编译后文件进行打包,生成jarwar等格式文件
  • 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>标签声明继承关系,继承父模块的groupIdversion,所以子模块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依赖junitlog4j

module_B:

    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.7</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

模块module_B依赖junit

module_Amodule_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>标签,在标签内列出子模块可能需要使用的构件及版本,当子模块使用到其中的构件时,在子模块内部声明构件的groupIdartifactId即可,以此进行版本控制。示例如下:

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中声明使用junitlog4j依赖,此时子模块会下载使用根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,该情况称为依赖传递,ABBC称为直接依赖,AC称为间接依赖。

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

AB依赖范围定义如左侧一列,BC依赖范围如上面一行,则AC的依赖性如下:

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

compile

test

provided

runtime

compile

compile

-

-

runtime

test

test

-

-

test

provided

provided

-

-

provided

runtime

runtime

-

-

runtime

根据表格结果可知,test、provided两个scope属性不具有传递性,所以BC依赖范围为这两个属性值的列,AC的依赖不存在;AB的依赖范围为这两个属性值的行,传递过来的依赖性降低为这两个属性值。compile、runtime两个scope属性具有传递性,runtime作用范围低于compile,按照木桶原则,构件传递时按照最小范围传递,AB的依赖范围为runtime的行,AC的依赖性降为runtimeAB的依赖范围为compile的行,AC的依赖性降低为BC的依赖性。

因为存在传递依赖的情况,所以可能会存在间接依赖构件版本不一致的情况,即依赖冲突。maven选择使用的构件版本规则为 最短路径优先,若存在 A->B->C->D 2.0A->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

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券