Maven实战-2.pom.xml标签说明

Hello姜先森

已于 2023-02-02 14:51:21 修改

阅读量2.2k

点赞数 4

分类专栏： Maven 文章标签： maven xml junit

于 2023-02-01 10:07:05 首次发布

本文链接：https://blog.csdn.net/weixin_37799575/article/details/128827170

版权

Maven 专栏收录该内容

8 篇文章 1 订阅

订阅专栏

前言

持续更新中…

pom.xml文件

1.<project>

这是pom.xml的根元素，所有的标签都包含在<project>…</project>之间。

2.<modelVersion>

指定当前POM模型的版本，对于maven2和maven3来说，它只能是4.0.0

<modelVersion>4.0.0</modelVersion>

3.<groupId>,<artifactId>和<version>

这三个元素定义了一个项目或其他的jar、pom、war的基本坐标。

<groupId>定义了项目属于哪个组，这个组往往和项目所在的组织或公司相关，例如在googlecode上建立一个项目myapp，那么<groupId>就是com.googlecode.myapp。

<artifactId>定义了当前项目在组中的唯一ID，例如定义为hello-world。可以这么理解，如果是单项目，artifactId可以和groupId的最后部分相同，否则artifactId就是子模块的名字即可。

<version>定义了项目的当前版本，例如1.0.0-SNAPSHOT。SNAPSHOT是快照的意思，后续会有说明。

4. <packaging>

定义Maven的打包方式，默认是jar。

如果是聚合模式，最外层的pom文件中的<packaging>的值必须是pom。

5.<classifier>

帮助定义构建输出的一些附属构建。classifier是不能直接定义的。

在这里插入图片描述

6.<name>

没有实际作用，只是可以起一个更友好的项目名称说明而已，不是必须的，但还是推荐为每个pom文件声明一个name。

7.<dependencies>

该元素下可以包含多个<dependency>元素，来声明项目的依赖。

8.<dependenciy>

8.1.<type>

依赖的类型，对应项目坐标定义的packaging，默认情况大部分都不定义，也就是jar类型。

8.2.<scope>

Maven因为执行一系列编译、测试和部署运行等操作，在不同的操作下使用的classpath不同，依赖范围就是用来控制依赖与三种 classpath（编译classpath、测试classpath、运行classpath）的关系。

用来指定被依赖资源的依赖范围，可选配置有 compile、test、provided、runtime、system、import，若不指定则默认 compile。

compile：编译依赖范围。如果没有指定，就会默认使用该依赖范围。使用此依赖范围的Maven 依赖，对于编译、测试、运行三种classpath 都有效。
test：测试依赖范围。使用此依赖范围的Maven依赖，只对于测试classpath有效，在编译主代码或者运行项目的使用时将无法使用此类依赖。典型的例子是JUnit,它只有在编译测试代码及运行测试的时候才需要。
provided：已提供依赖范围。使用此依赖范围的Maven依赖，对于编译和测试classpath有效，但在运行时无效（对运行的classpath无效）。典型的例子是 servlet-api, 编译和测试项目的时候需要该依赖，但在运行项目的时候，由于容器已经提供，就不需要Maven重复地引人一遍。
runtime：运行时依赖范围。使用此依赖范围的Maven依赖，对于测试和运行class-path有效，但在编译主代码时无效（对编译的classpath无效）。典型的例子是JDBC驱动实现，项目主代码的编译只需要JDK提供的JDBC接口，只有在执行测试或者运行项目的时候才需要实现上述接口的具体JDBC驱动。
system：系统依赖范围。该依赖与三种 classpath 的关系，和 provided 依赖范围完全一致。但是，system 范围的依赖不会从 maven 仓库下载，而是从本地文件系统获取，使用 system 范围的依赖时必须通过元素显式地指定依赖文件的路径。由于此类依赖不是通过 Maven 仓库解析的，而且往往与本机系统绑定，可能造成构建（构建的产物有：classes和artifact）的不可移植，因此应该谨慎使用。
import：导入依赖范围，该依赖范围不会对三种 classpath 产生影响，该依赖范围只能与 <dependencyManagement> 元素配合使用，其功能为将目标pom.xml 文件中元素 <dependencyManagement> 的配置导入合并到当前 pom.xml 文件的元素 <dependencyManagement> 中。 <dependencyManagement> 的用法参考这里

在这里插入图片描述

8.3.<optional>

标记依赖是否可选的。

例如项目A依赖于项目B，项目B依赖于项目X和项目Y，B对于X和Y的依赖都是可选的，此时X和Y的项目的<optional>就是true，X和Y不会对A有任何影响，只会对B产生影响（也就是A依赖于B，X和Y不会传递依赖给A，如果A需要用到X或Y，需要显示声明出来这个依赖X或Y）。

8.4.<exclusions>

用来排除传递性依赖。可以包含一个或者多个<exclusion>元素。

8.5.<exclusion>

声明此元素的时候只需要指定groupId和artifactId即可，不需要version，因为Maven解析后的依赖中，不可能存在groupId和artifactId相同而version不同的两个依赖。

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-jdbc</artifactId>
   <exclusions>
       <exclusion>
           <artifactId>spring-boot-starter-logging</artifactId>
           <groupId>org.springframework.boot</groupId>
       </exclusion>
   </exclusions>
</dependency>

9.<plugins>

位置在<project>下面，可包含多个<plugin>。

如果<plugin>中配置的插件时Maven的官方插件，可以不写groupId，因为他们的统一groupId都是org.apache.maven.plugins，所以可以省略。

9.1.<executions>

配置插件的执行，下面可以包含多个<execution>，每个<execution>子元素用来配置一个执行任务，该配置中有id，phase，goals元素，分别表示任务ID，绑定到生命周期的哪个阶段，要执行的插件目标。

<plugin>
     <groupId>org.apache.maven.plugins</groupId>
     <artifactId>maven-source-plugin</artifactId>
     <executions>
         <execution>
         	 <!-- 任务ID -->
             <id>attach-sources</id>
             <!-- 插件绑定到哪个生命周期的阶段 -->
             <phase>verify</phase>
             <goals>
             	 <!-- 要执行的插件的目标	 -->
                 <goal>jar-no-fork</goal>
             </goals>
         </execution>
     </executions>
 </plugin>

如上配置好之后，测试一下，执行mvn clean install（verify阶段在intall阶段之前执行），只截图相关部分，如下：
在这里插入图片描述
其实上面配置也可以取消verify，因为这个插件目标jar-no-fork默认配置到了生命周期package阶段，可以通过命令mvn help:describe查看，详细参考 Maven实战-1.maven命令。

9.2.<configuration>

为Maven插件进行全局参数配置，例如

 <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <configuration>
    	<!-- 编译源文件使用jdk1.8的版本 -->
        <source>1.8</source>
        <target>1.8</target>
    </configuration>
</plugin>

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <!-- 避免Maven命令行还要输入-Dmaven.test.skip=true, 直接这里全局配置好 -->
        <skip>true</skip>
    </configuration>
</plugin>

如果是配置在插件目标任务<execution>下，表示为当前插件任务配置特定参数：
在这里插入图片描述

10.<properties>

<properties>…<properties/>之间可以来定义Maven属性，例如定义一些jar包依赖的统一version，使用的地方直接用${versionName}即可。

<properties>
	<!-- 类似java.version的名称自己定义 -->
	<java.version>1.8</java.version>
</properties>

<!-- 引用Java.version -->
<dependencies>
	<dependency>
		<groupId>...</groupId>
		<artifactId>test1</artifactId>
		<version>${java.version}</version>
	</dependency>
	<dependency>
		<groupId>...</groupId>
		<artifactId>test2</artifactId>
		<version>${java.version}</version>
	</dependency>
</dependencies>

11.<repositories>

在此元素下，可以声明一个或多个<repository>，表示远程仓库。

<repositories>
    <repository>
    	<!-- 这里配置一个id为jboss,名称为JBoss..tory的远程仓库 -->
        <id>jboss</id>
        <name>JBoss Maven Repository</name>
        <!-- 指向仓库的地址,一般都基于http协议 -->
        <url>http://repository.jboss.com/maven2/</url>
        <!-- 开启远程仓库对发布(正式)版本的下载支持 -->
        <releases>
            <enabled>true</enabled>
        </releases>
        <!-- 关闭远程仓库对快照版本的下载支持 -->
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
        <layout>default</layout>
    </repository>
</repositories>

注意，任何一个<repositories>配置的远程仓库中，id必须是唯一的，尤其需要注意的是，Maven默认的远程仓库地址的id是central，如果其他仓库使用了此id，就会覆盖默认的远程仓库。

因为<releases>和<snapshots>的配置，Maven只会从此远程仓库下载正式版本的构件，不会下载快照版本的。

对于<releases>和<snapshots>的配置，除了<enable>，还包括另外两个子元素<updatePolicy>和<checksumPolicy>

updatePolicy：配置Maven从远程仓库检查更新的频率，默认的值是daily，表示Maven每天更新一次，其他可配置的值是：never（从不），always（每次构建都检查），interval:X（每隔X分钟检查一次）
checksumPolicy：配置Maven检查校验和文件的策略，当构件部署到Maven仓库时会同时部署对应的校验和文件，其他项目引用下载构件的时候，Maven会验证校验和文件，如果校验和验证失败，根据值进行操作，checksumPolicy的默认值是warn，Maven构建时会会输出警告信息，值是fail，Maven会让构建失败，值是ignore，使Maven完全忽略校验和错误。

如果配置的远程仓库需要用户名和密码，就需要在setting文件中进行认证信息的配置，参考Maven实战-3.setting.xml标签说明。

12.<distributionManagement>

将项目生成的构建部署到仓库中。

<distributionManagement>  
    <repository>  
        <id>nexus-releases</id>
        <name>releases repository</name>  
        <url>http://172.17.103.59:8081/nexus/content/repositories/releases</url>  
    </repository>  
    <snapshotRepository>  
        <id>nexus-snapshots</id>
        <name>snapshots repository</name>    
        <url>http://172.17.103.59:8081/nexus/content/repositories/snapshots</url>  
    </snapshotRepository>  
</distributionManagement>

如上，<distributionManagement>中包含<repository> 和<snapshotRepository> 子元素，前者表示发布版本构件的仓库，后者表示快照版本构件的仓库。这两个元素下都需要id，name和url三个子元素，id为该远程仓库的唯一标识，name是为了阅读理解，关键的是url指向的仓库地址。

13.<pluginRepositories>

<pluginRepositories>下面可以有多个<pluginRepository>，每一个都表示插件远程仓库的配置。

注意：Maven会区别对待依赖的远程仓库和插件的远程仓库，当Maven需要的依赖在本地仓库不存在时，它会去所配置的远程仓库查找，而插件如果不存在本地仓库时，它就不回去远程仓库查询。

配置插件远程仓库如下：
在这里插入图片描述
如上，插件远程仓库的配置，除了<pluginRepositories>和<pluginRepository>不同之外，里面的其他元素和依赖的远程仓库配置一样。这里的配置关闭了快照版本的支持。

一般来说中央仓库包含的插件满足日常需求了，因此也不需要配置插件远程仓库。只有中央仓库不存在或自己编写了插件，才考虑上面的配置。

14.<testResources>

开启资源过滤。

15.<modules>

聚合的最核心配置之一（另一个是<packaging>值必须为pom），<modules>中可以声明任意个<module>来实现模块的聚合。这里配置的每个<module>的值都是当前POM文件的相对目录。
在这里插入图片描述
如果是聚合的父子目录结构，最外层POM文件中的如下

<modules>
	<module>account-email</module>
	<module>account-persist</module>
</modules>

如果是平行目录结构，如下

<modules>
	<module>../account-email</module>
	<module>../account-persist</module>
</modules>

16.<parent>

声明父模块，<parent>下的groupId，artifactId和version制定了父模块的坐标，这三个元素是必须的。

16.1.<relativePath>

表示父模块POM文件的相对路径。默认值是…/pom.xml，也就是说Maven默认父POM在上一层目录中。

17.<description>

项目的描述信息

18.<dependencyManagement>

在此元素下声明的依赖（<dependencies><dependency>），自己和继承的子模块都不会引入实际的依赖，但是子模块会继承这段配置。

子模块需要哪个依赖，只需要在自己的POM中，<dependencies><dependency>下声明groupId和artifactId即可（需要和父POM中<dependencyManagement>的一致）,无需声明version和scope，因为它都从配置<dependencyManagement>中得到（上面加粗的那段话）。

如果子模块不声明依赖的使用，虽然父模块中定义了<dependencyManagement>，但不会对子模块产生任何实际影响。

如果子模块中定义了和父POM<dependencyManagement>中相同的groupId和artifactId，并且！又定义了version，那么就会覆盖父POM的version使用自己定义的！！！