Maven生命周期，依赖范围

原飞木

已于 2024-09-13 16:39:05 修改

阅读量3.4k

点赞数 3

分类专栏： Maven 文章标签： maven-compiler-plugin 生命周期依赖范围依赖传递资源打包

于 2019-05-17 14:45:18 首次发布

本文链接：https://blog.csdn.net/BushQiang/article/details/89926347

版权

Maven 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

本文详细介绍了Maven的生命周期，包括验证、编译、测试、打包、验证、安装和部署等阶段。同时，解释了Maven的依赖范围，如compile、test、provided、runtime和system，并强调了依赖传递和版本调解原则。此外，还讨论了如何在POM中排除依赖、dependencyManagement与dependencies的区别，以及maven-compiler-plugin、spring-boot-maven-plugin和maven-resources-plugin等关键插件的配置和作用。

摘要由CSDN通过智能技术生成

maven生命周期

构建生命周期是由阶段组成的：

这些构建生命周期中的每一个由构建阶段的不同列表定义，其中构建阶段表示生命周期中的阶段。

例如，默认（default）的生命周期包括以下阶段（注意：这里是简化的阶段，用于生命周期阶段的完整列表，请参阅下方生命周期参考）：

验证（validate） - 验证项目是否正确，所有必要的信息可用
编译（compile） - 编译项目的源代码
测试（test） - 使用合适的单元测试框架测试编译的源代码。这些测试不应该要求代码被打包或部署
打包（package） - 采用编译的代码，并以其可分配格式（如JAR）进行打包。
验证（verify） - 对集成测试的结果执行任何检查，以确保满足质量标准
安装（install） - 将软件包安装到本地存储库中，用作本地其他项目的依赖项
部署（deploy） - 在构建环境中完成，将最终的包复制到远程存储库以与其他开发人员和项目共享。
这些生命周期阶段（以及此处未显示的其他生命周期阶段）依次执行，以完成默认生命周期。给定上述生命周期阶段，这意味着当使用默认生命周期时，Maven将首先验证项目，然后尝试编译源代码，运行这些源代码，打包二进制文件（例如jar），运行集成测试软件包，验证集成测试，将验证的软件包安装到本地存储库，然后将安装的软件包部署到远程存储库。

换句话说，在生命周期里面阶段是连续的，在不出错的前提下，比如执行打包（package）时就一定是执行了测试（test）之后再执行。

maven依赖范围

有哪些依赖范围
Scope：依赖范围（compile,test,provided,runtime,system 五种状态）

编译依赖范围（compile），该范围就是默认依赖范围，此依赖范围对于编译、测试、运行三种classpath都有效，举个简单的例子，假如项目中有spring-core的依赖，那么spring-core不管是在编译，测试，还是运行都会被用到，因此spring-core必须是编译范围（构件默认的是编译范围，所以依赖范围是编译范围的无须显示指定）

     <dependency>
  	  <groupId>org.springframework</groupId>
  	  <artifactId>spring-core</artifactId>
  	  <version>2.5</version>
  	  <scope>compile</scope> <!--默认为该依赖范围，无须显示指定-->
    </dependency>

测试依赖范围(test)，顾名思义就是针对于测试的，使用此依赖范围的依赖，只对测试classpath有效，在编译主代码和项目运行时，都将无法使用该依赖，最典型的例子就是 Junit, 构件在测试时才需要，所以它的依赖范围是测试，因此它的依赖范围需要显示指定为test ,当然不显示指定依赖范围也不会报错，但是该依赖会被加入到编译和运行的classpath中,造成不必要的浪费。

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

已提供依赖范围(provided),使用该依赖范围的maven依赖，只对编译和测试的classpath有效，对运行的classpath无效，典型的例子就是servlet-api，编译和测试该项目的时候需要该依赖，但是在运行时，web容器已经提供的该依赖，所以运行时就不再需要此依赖，如果不显示指定该依赖范围，并且容器依赖的版本和maven依赖的版本不一致的话，可能会引起版本冲突，造成不良影响。

 <dependency>
  	  <groupId>javax-servlet</groupId>
  	  <artifactId>servlet-api</artifactId>
  	  <version>2.0</version>
  	 <scope>provided</scope>
    </dependency>

运行时依赖范围(runtime),使用该依赖范围的maven依赖，只对测试和运行的classpath有效，对编译的classpath无效，典型例子就是JDBC的驱动实现，项目主代码编译的时候只需要JDK提供的JDBC接口，只有在测试和运行的时候才需要实现上述接口的具体JDBC驱动。
系统依赖范围（system）,该依赖与classpath的关系与 provided依赖范围完全一致，但是系统依赖范围必须通过配置systemPath元素来显示指定依赖文件的路径，此类依赖不是由maven仓库解析的，而且往往与本机系统绑定，可能造成构件的不可移植，因此谨慎使用，systemPath元素可以引用环境变量：

        <dependency>
            <groupId>javax.sql</groupId>
            <artifactId>jdbc-stext</artifactId>
            <version>2.0</version>
            <scope>system</scope>
            <systemPath>${java.home}/lib/rt.jar</systemPath>
        </dependency>

依赖传递

maven引入的传递性依赖机制，一方面大大简化和方便了依赖声明，另一方面，大部分情况下我们只需要关心项目的直接依赖是什么，而不用考虑这些直接依赖会引入什么传递性依赖。但有时候，当传递性依赖造成问题的时候，我们就需要清楚地知道该传递性依赖是从哪条依赖路径引入的。

maven对于依赖相同的资源，默认会做出以下优化：

第一原则：以短路径长度为准
例如，项目A有这样的依赖关系： A–>B–>C–>X(1.0)、A–>D–>X(2.0)，X是A的传递性依赖，但是两条依赖路径上有两个版本的X，那么哪个X会被maven解析使用呢？两个版本都被解析显然是不对的，因为那会造成依赖重复，因此必须选择一个。maven依赖调解的第一原则：路径最近者优先。该例中X(1.0)的路径长度为3，而X(2.0)的路径长度为2，因此X(2.0)会被解析使用。

第二原则：相同路径长度时，以pom中声明顺序为准
依赖调解第一原则不能解决所有问题，比如这样的依赖关系：A–>B–>Y(1.0)，A–>C–>Y(2.0)，Y(1.0)和Y(2.0)的依赖路径长度是一样的，都为2。那么到底谁会被解析使用呢？在maven2.0.8及之前的版本中，这是不确定的，但是maven2.0.9开始，为了尽可能避免构建的不确定性，maven定义了依赖调解的第二原则：第一声明者优先。在依赖路径长度相等的前提下，在POM中依赖声明的顺序决定了谁会被解析使用。顺序最靠前的那个依赖优胜。

maven中去除依赖

maven pom中配置 exclusion标签手动去除依赖

    <dependency>
      <groupId>sample.ProjectA</groupId>
      <artifactId>Project-A</artifactId>
      <version>1.0</version>
      <scope>compile</scope>
      <exclusions>
        <exclusion>  <!-- declare the exclusion here -->
          <groupId>sample.ProjectB</groupId>
          <artifactId>Project-B</artifactId>
        </exclusion>
      </exclusions>
    </dependency>

dependencyManagement与dependencies区别

dependencies即使在子项目中不写该依赖项，那么子项目仍然会从父项目中继承该依赖项（全部继承）

dependencyManagement里只是声明依赖，并不实现引入，因此子项目需要显示的声明需要用的依赖。如果不在子项目中声明依赖，是不会从父项目中继承下来的；只有在子项目中写了该依赖项，并且没有指定具体版本，才会从父项目中继承该项，并且version和scope都读取自父pom;另外如果子项目中指定了版本号，那么会使用子项目中指定的jar版本。

maven插件配置说明

maven-compiler-plugin

maven是个项目管理工具，如果我们不告诉它我们的代码要使用什么样的jdk版本编译的话，它就会用maven-compiler-plugin默认的jdk版本来进行处理，这样就容易出现版本不匹配，以至于可能导致编译不通过的问题。

        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-compiler-plugin</artifactId>
          <version>3.1</version>
          <configuration>
            <source>1.8</source>
            <target>1.8</target>
          </configuration>
        </plugin>

spring-boot-maven-plugin

在添加了该插件之后，当运行“mvn package”进行打包时，会打包成一个可以直接运行的 JAR 文件，使用“Java -jar”命令就可以直接运行。这在很大程度上简化了应用的部署，只需要安装了 JRE 就可以运行。
可以在POM中，指定生成的是Jar还是War。

        <plugin>
          <groupId>org.springframework.boot</groupId>
          <artifactId>spring-boot-maven-plugin</artifactId>
          <version>2.0.3.RELEASE</version>
          <configuration>
            <!--debug 能够断点-->
            <jvmArguments>
              -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005
            </jvmArguments>
          </configuration>
        </plugin>

maven-resources-plugin

该插件的作用主要是处理将主程序与测试程序所需的源文件复制到输出编译文件夹中。
构建Maven项目的时候，如果没有进行特殊的配置，Maven会按照标准的目录结构查找和处理各种类型文件。

1）src/main/java和src/test/java目录下的所有*.java文件分别在comile和test-comiple阶段被编译，编译结果分别放到了target/classes和targe/test-classes目录中，但是这两个目录中的其他文件都会被忽略掉。

2）src/main/resouces和src/test/resources这两个目录中的文件也会分别被复制到target/classes和target/test-classes目录中。

但是会出现如下情况

1）放在src/main/java下的xml文件，比如mybatis中的mapper.xml，是不会被默认加载的。

2）想要排除默认加载的某些文件，比如我不想加载init.json文件

这个时候就要用到标签和maven-resources-plugin插件了，用法如下：

resource的filtering属性用来表示资源文件中的占位符是否需要被替换，true为需要替换。
false为不需要替换。

    <resources>
      <resource>
        <directory>src/main/resources</directory>
        <filtering>true</filtering>
      </resource>
      <resource>
        <directory>src/main/java</directory>
        <includes>
          <include>**/*.xml</include>
        </includes>
      </resource>
    </resources>

maven打包项目的时候pom.xml配置文件里可以配置对项目进行统一编码，但是部分文件可能不需要进行重新编码，例如：证书文件；重新编码后可能导致证书不可用。

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-resources-plugin</artifactId>
                <configuration>
                    <nonFilteredFileExtensions>
                        <nonFilteredFileExtension>xlsx</nonFilteredFileExtension>
                        <nonFilteredFileExtension>xls</nonFilteredFileExtension>
                        <nonFilteredFileExtension>zip</nonFilteredFileExtension>
                        <nonFilteredFileExtension>cer</nonFilteredFileExtension>
                        <nonFilteredFileExtension>pfx</nonFilteredFileExtension>
                        <nonFilteredFileExtension>py</nonFilteredFileExtension>
                        <nonFilteredFileExtension>keystore</nonFilteredFileExtension>
                    </nonFilteredFileExtensions>
                </configuration>
            </plugin>