读书replay《maven实战》.2.20190613

朴灿烈づ我的快乐病毒、 2022-01-14 02:37 206阅读 0赞

[2019独角兽企业重金招聘Python工程师标准>>> ][2019_Python_] ![hot3.png][]

# 前情提要 #

maven这个工具用了好久了，但是一直都用的迷迷糊糊的，没有对它进行过系统性的学习，只是知道一些常用的功能怎么实现，所以20190516这一天我从JD购买了徐晓斌老师所著的《maven实战》一书，准备系统性的学习一下maven。

# pom结构 #

我工作的主力语言是java，spring框架这个体系，所以pom文件天天见。

该文件下，有用来声明当前项目坐标的<groupId>,<artifactId>,<name>,<version>这几个字段。还有用来声明依赖的<dependencies>。以及用来声明插件的<build>。

# 坐标 #

maven使用由<groupId>,<artifactId>,<version>构成的坐标来唯一确认一个构件（任何类型的maven项目都可被理解为构件）。既然是坐标，那么<groupId>,<artifactId>,<version>的指向就具有唯一性。<version>的命名有有无“-SNAPSHOT”的区别，如果在版本后加了“-SNAPSHOT”，则表示该版本是一个快照版，是不稳定的。快照版有它独特的用处：当你依赖了一个快照版的构件时，maven会在打包时去检查本地仓库中该快照的最新代码（maven默认会每天和远程仓库同步一次数据，这是可以配置的，具体请查阅书籍或者文档），例如，B构件依赖了A构件的“0.1-SNAPSHOT”版本，我给A添加了一些代码，并在仓库重新deploy了一次A的“0.1-SNAPSHOT”。此时你重新构建B，A的“0.1-SNAPSHOT”的新代码就已经被包含进去了。如果没有“-SNAPSHOT”的帮助，B要想使用A的新特性，A需要以新的版本号发布，B需要修改pom去依赖新版本的A，本质上是A提供了新版本坐标，B去依赖新版本。而快照版则是，AB都不修改坐标，但B能使用A的新代码。至于maven是怎么实现的，大家想知道就去看书吧，我就不赘述了，大概就是maven对快照会维护另一个它自己生成的版本号。

# 依赖 #

依赖有两个点需要注意，一是依赖的范围，二是依赖的传递性。

## 依赖范围 <scope> ##

依赖范围有6：compile,test,provided,runtime,system,import

在介绍这几个范围之前，还需要介绍一个叫做classpath的概念，我个人理解它是编译环境的意思，我没深究。maven有3套classpath，一是编译classpath，二是测试classpath，三是运行时classpath。依赖范围会决定一个构件是否被纳入某个classpath。比如，junit依赖范围选则test，则运行时classpath就不会包含junit包。

编译环境对各个依赖范围的关系是： compile表示进入所有classpath。test表示只进入测试classpath。provided表示进入编译和测试classpath。runtime表示进入运行时和测试classpath。system和provided一致（但system需要多一个<systemPath>参数标签做配合，它是用来引入非maven仓库包的）。inport比较特殊，是用来支撑maven聚合与继承特性的，它和依赖范围没关系，后文再介绍。

默认是compile范围，常见的情况就是给一个test范围，表示只在测试classpath有效，这样在最后的打包文件中，就不会把一些用来测试的包也收录进去，节省空间。

## 依赖传递性 ##

假如：A依赖B，B依赖C。

从A的角度来说，A对B是第一直接依赖，A对C是传递性依赖，B对C是第二直接依赖。

*  当第二直接依赖是compile时，传递性依赖的范围和第一直接依赖范围一致。（如C是B的compile依赖，则B是A的什么范围依赖，C就是A的什么范围依赖）。
 *  当第二直接依赖是test时，依赖不会传递。
 *  当第二直接依赖是provided时，只在第一直接依赖为provided时传递，并也是以provided范围传递的。（如c->b=provided,b->a=provided,c->a=provided）
 *  当第二直接依赖是runtime的时候，传递性依赖与第一直接依赖的范围一致，除了compile，它会被传递为runtime。（如c->b=runtime,b->a=compile,c->a=runtime。如c->b=runtime,b->a=test,c->a=test）

最后，有一个叫做<optional>的选项，当它被设置为true时，整个依赖不会被传递。对A来说，看起来就像B没有依赖C一样。此时，A要成功编译，它得自己添加一个C依赖。这个功能是用来解决某些接口有多种实现的场景。到需要的时候大家去查阅书籍吧。此时只要知道有这么个功能就行。

# 插件 #

maven归根到底是个编译工具，maven将编译任务拆成了一堆特定的任务，这些任务就组成了maven的生命周期。

**三大任务：clean，default，site**

*  clean中的子任务
    
     *  pre-clean
     *  clean
     *  post-clean
 *  default中的子任务
    
     *  validate
     *  initialize
     *  generate-sources
     *  process-sources
     *  generate-resources
     *  process-resources
     *  compile
     *  process-classes
     *  generate-test-sources
     *  process-test-sources
     *  generate-test-resources
     *  process-test-resources
     *  test-compile
     *  process-test-classes
     *  test
     *  prepare-package
     *  pachage
     *  pre-integration-test
     *  integration-test
     *  post-integration-test
     *  verify
     *  install
     *  deploy
 *  site中的子任务
    
     *  pre-site
     *  site
     *  post-site
     *  site-deploy

上面列举的任务是按照maven执行的顺序罗列的。 maven给其中的某几个子任务绑定了默认的执行器，包括clean，compile，test，pachage，install，deloy等，所以拿到maven后你什么都不配置，也能执行mvn clean，mvn install 这样的命令。这些任务的功能我没有记，不过只需要知道大概有这么个体系就行，什么时候需要了，什么时候再去查阅书籍就可以。

看到这些任务，你有没有一种似曾相识的感觉，反正我看到这些任务的时候，顿时就明白，命令行上输入的`mvn clean install`是什么了，很亲切。实际上，但你在命令行执行mvn指令的时候，就是告诉maven，去执行哪个子任务，而由于任务有先后顺序，所以maven会从第一个任务开始执行，直到你指定的任务为止。而clean，default，site这三个大任务是各自独立的。mvn clean install表示：执行clean任务中的clean子任务，和default任务中的install任务。所以`mvn clean install`的完整写法其实是：`mvn clean:clean default:install`。于是maven会从pre-clean执行到clean，以及从validate执行到install。

认识了任务（也就是maven的生命周期），我们就可以认识插件了。maven插件有一个概念叫：goal，也就是目标。这个goal可以理解为是一个方法，用来执行一些逻辑。maven会根据你的配置，把插件的goal绑定到任务上，这个任务在maven中叫做phase！所以还记得你配置插件的时候怎么写的吗？

在plugins标签下，申明一个插件，给定插件坐标（groupId,artifactId,version...），设置执行器，将执行器绑定到某个phase（生命周期）上，指定执行什么goal（也就是插件的动作）。如此一来，当maven经过相应任务的时候，就会使用你配置的插件中的goal。

maven不仅支持通过mvn命令行调用生命周期阶段，还支持直接调用插件的goal。我现在最常用的莫非 mvn clean spring-boot:run 。这其中的spring-boot:run,就是

<plugin>
    	<groupId>org.springframework.boot</groupId>
    	<artifactId>spring-boot-maven-plugin</artifactId>
    </plugin>

这个插件提供的功能，这里我们直接调用了spring-boot（spring-boot-maven-plugin的name）插件的run这个goal。

maven自身提供了dependence这个插件，用来查看项目依赖，有兴趣的同学可以去查阅一下，它对于优化项目依赖有很大作用。

# maven属性 #

maven允许你在pom文件中使用"$\{\}"语法来引用属性，那么maven提供了哪些属性，我们如何自己声明属性，就是需要学习的。此处不需要记住，需要时回头来看这部分的总结就可以了。

maven一共提供了6类属性，分别如下：

*  内置属性
    
    内置属性主要有常用的两个
    
     *  $\{basedir\}
        
        表示项目的根目录，也就是包含pom文件的那个目录
     *  $\{version\}
        
        表示项目版本
 *  POM属性
    
    这些属性和POM元素对应，其中一些具有默认值，默认值已在超级POM中定义好了。常见的如下。
    
     *  $\{project.build.sourceDirectory\}
        
        项目的源码目录：src/main/java/
     *  $\{project.build.testSourceDirectory\}
        
        项目的测试源码目录：src/test/java/
     *  $\{project.build.directory\}
        
        项目构建输出目录：target/
     *  $\{project.outputDirectory\}
        
        项目源码编译输出目录：target/classes/
     *  $\{project.testOutputDirectory\}
        
        项目测试源码编译输出目录：target/test-classes/
     *  $\{project.groupId\}，$\{project.artifactId\}，$\{project.version\}
        
        项目坐标
     *  $\{project.build.finalName\}
        
        项目打包后的文件名，默认：$\{project.artifactId\}-$\{project.version\}
 *  自定义属性
    
    在POM的<properties>元素下自定义的maven属性，在其他地方用`${xxx}`形式使用，maven会自动替换。
 *  Settings属性
    
    原理和POM属性相似，只不过Settings属性需要用户使用`${settings.xxx}`的形式，来引用settings.xml文件中的XML元素属性。常用的有
    
     *  $\{settings.localRepository\}
        
        用户本地仓库的地址
 *  Java系统属性
    
    所有java系统属性，maven都可以引用，详细信息可通过`mvn help:system`指令查看。
 *  环境变量属性
    
    所有环境变量，maven都可通过`${env.xxx}`的形式引用。

# 资源过滤 #

maven的属性不仅在POM中可以引用，在其他资源文件中也可以引用，只需要设定过滤器就可以。我以spring-boot项目为例，spring-boot项目需要通过<parent>标签设定一个spring boot starter为父工程。如：

<parent>
    	<groupId>org.springframework.boot</groupId>
    	<artifactId>spring-boot-starter-parent</artifactId>
    	<version>1.5.21.RELEASE</version>
    	<relativePath/> 
    </parent>

打开这个父工程的pom你会发现有这样一段配置

<build>
    	<resources>
    		<resource>
    			<directory>${basedir}/src/main/resources</directory>
    			<filtering>true</filtering>
    			<includes>
    				<include>**/application*.yml</include>
    				<include>**/application*.yaml</include>
    				<include>**/application*.properties</include>
    			</includes>
    		</resource>
    		<resource>
    			<directory>${basedir}/src/main/resources</directory>
    			<excludes>
    				<exclude>**/application*.yml</exclude>
    				<exclude>**/application*.yaml</exclude>
    				<exclude>**/application*.properties</exclude>
    			</excludes>
    		</resource>
    	</resources>
    </build>

原理是，maven使用插件maven-resources-plugin来将项目的资源文件复制到编译输出文件夹下去，通过在<build>标签下申明<resources><resource>标签，你可以改变插件maven-resources-plugin的行为。可以看到，spring boot starter的配置启动了filter去过滤形如\*\*/application\*.yml的文件，过滤器会将资源文件中的`${xxx}`自动替换为pom属性。

转载于:https://my.oschina.net/u/3039151/blog/3054187

[2019_Python_]: https://my.oschina.net/u/2663968/blog/3061697
[hot3.png]: /images/20220113/cbc4cd338535433895765f27763cd4f0.png