maven学习（三）

亦凉 2022-05-23 03:45 56阅读 0赞

## 生命周期和插件 ##

> 包括项目的清理、初始化、编译、测试、打包、集成测试、验证、部署和站点生成  
> maven的生命周期是抽象的，这意味着生命周期本身不做任何实际工作。每个构建步骤都可以绑定一个或者多个插件行为，而且maven为大多数构建步骤编写并绑定了默认插件，针对编译的maven-compiler-plugin，针对测试的maven-surefire-plugin，用户几乎不会觉察到插件的存在。

## 三套生命周期 ##

> clean 目的是清理项目  
> default 目的是构建项目  
> site 目的是建立项目的站点

**每个生命周期包含一些阶段（phase）**

**clean生命周期**

> pre-clean 执行上一次清理前需要完成的工作  
> clean：清理上一次构建生成的文件  
> post-clean 执行一些清理后需要完成的工作

**default生命周期**

> validate  
> 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  
> package 接受编译好的代码，打包成可发布的格式，如 JAR 。  
> pre-integration-test  
> integration-test  
> post-integration-test  
> verify  
> install 将包安装至本地仓库，以让其它项目依赖。  
> deploy 将最终的包复制到远程的仓库，以让其它开发人员与项目共享。  
> **site生命周期**  
> pre-site  
> site ：生成项目的站点文档；  
> post-site  
> site-deploy ：发布生成的站点文档

## 聚合和继承 ##

**Maven聚合（或者称为多模块）**

> Maven聚合（或者称为多模块），是为了能够使用一条命令就构建多个模块，例如已经有两个模块，分别为account-email,account-persist，我们需要创建一个额外的模块（假设名字为account-aggregator，然后通过该模块，来构建整个项目的所有模块，accout-aggregator本身作为一个Maven项目，它必须有自己的POM,不过作为一个聚合项目，其POM又有特殊的地方，看下面的配置：

<project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd>
            <modelVersion>4.0.0</modelVersion>
            <groupId>com.juvenxu.mvnbook.account</groupId>
            <artifact>account-aggregator</artifact>
            <version>1.0.0-SNAPSHOT</version>
            <packaging>pom</packaging>
            <name>Account Aggregator</name>
            <modules>
                <module>account-email</module>
                <module>account-persist</module>
            </modules>
    </project>

> 上面有一个特殊的地方就是packaging,其值为pom,如果没有声明的话，默认为jar，对于聚合模块来说，其打包方式必须为pom，否则无法构建。
> 
> modules里的每一个module都可以用来指定一个被聚合模块，这里每个module的值都是一个当前pom的相对位置，本例中account-email、account-persist位于account-aggregator目录下，当三个项目同级的时候，上面的两个module应该分别为../account-email和../account-persist

**继承**

> 在构建多个模块的时候，往往会多有模块有相同的groupId、version，或者有相同的依赖，例如：spring-core、spring-beans、spring-context和junit等，或者有相同的组件配置，例如：maven-compiler-plugin和maven-resources-plugin配置，在Maven中也有类似Java的继承机制，那就是POM的继承。

**继承POM的用法**

> 面向对象设计中，程序员可以通过一种类的父子结构，在父类中声明一些字段和方法供子类继承，这样可以做到“一处声明、多处使用”，类似的我们需要创建POM的父子结构，然后在父POM中声明一些配置，供子POM继承。

下面声明一个父POM，如下：

> 这个父POM中，groupId和version和其它模块一样，它的packaging为pom，这一点和聚合模块一样，作为父模块的POM，其打包类型也必须为pom,由于父模块只是为了帮助消除配置的重复，因此它本身不包含除POM之外的项目文件，也就不需要src/main/java之类的文件夹了。

有了父模块，就需要其它模块来继承它。首先将account-email的POM修改如下：

account-email继承account-parent的POM

> 上面POM中使用parent元素声明父模块，parent下的子元素groupId、artifactId和version指定了父模块的坐标，这三个元素是必须的。元素relativePath表示了父模块POM的相对位置。当项目构建时，Maven会首先根据relativePath检查父POM，如果找不到，再从本地仓库查找。relativePath的默认值是../pom.xml,Maven默认父POM在上一层目录下。

--------------------

> 上面POM没有为account-email声明groupId，version,不过并不代表account-email没有groupId和version，实际上，这个子模块隐式的从父模块继承了这两个元素，这也就消除了不必要的配置。上例中，父子模块使用了相同的groupId和version，如果遇到子模块需要使用和父模块不一样的groupId或者version的情况，可以在子模块中显式声明。对于artifactId元素来说，子模块更应该显式声明，因为如果完全继承groupId、artifactId、version,会造成坐标冲突；另一方面，即使使用不同的groupId或version,同样的artifactId容易造成混淆。

account-persist继承account-parent的POM

最后，同样需要把account-parent加入到聚合模块accountp-aggregator中，代码如下：

将account-parent加入到聚合模块

**可继承的POM元素**

> **groupId**:项目组ID,项目坐标的核心元素  
> **version**:项目版本,项目坐标的核心元素  
> **description**:项目的描述信息  
> **organnization**:项目的组织信息  
> **inceptionYear**:项目的创始年份  
> **url:**项目的URL地址  
> **developers**:项目的开发者信息  
> **contributors**:项目的贡献者信息  
> **distributionManagement**:项目的部署配置  
> **issueManagement:**项目的缺陷跟踪系统信息  
> **ciManagement:**项目的集成信息  
> **scm**:项目的版本控制系统信息  
> **mailingLists:**项目的邮件列表信息  
> **properties**:自定义的Maven属性  
> **dependencies:**项目的依赖配置  
> **dependencyManagement**:项目的依赖管理配置  
> **repositories**:项目的仓库配置  
> **build:**包括项目的源码目录配置、输出目录配置、插件配置、插件管理配置等  
> **reporting:**包括项目的报告输出目录配置，报告插件配置等。

**依赖管理**

> 当多有模块中有相同的依赖时，我们可以将这些依赖提取出来，同意在父POM中声明，这样就可以简化子模块的配置了，但是这样还是存在问题，当想项目中加入一些，不需要这么多依赖的模块，如果让这个模块也依赖那些不需要的依赖，显然不合理。

--------------------

> Maven提供的dependentcyManagement元素既能让子模块继承到父模块的依赖配置，又能保证子模块依赖使用的灵活度。在dependentcyManagement元素下的依赖声明不会引入实际的依赖，不过他能够约束denpendencies下的依赖使用。对上面的accoun-parent进行改进，代码如下：

<project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:shemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.juvenxu.mvnbook.account</groupId> <artifactId>account-parent</artifactId> <version>1.0.0-SNAPSHOT</version> <packaging>pom</packaging> <name>Account Parent</name <properties> <springframework.version>2.5.6</springframework.version> <junit.version>4.7</junit.version> </properties> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> <version>${springframework.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-beans</artifactId> <version>${springframework.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>${springframework.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context-support</artifactId> <version>${springframework.version}</version> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>${springframework.version}</version> <scope>test</scope> </dependency> </dependencies> </dependencyManagement> </project>

上面使用了dependencyManagement声明的依赖既不会给account-parent引入依赖，也不会给它的子模块引入依赖，不过这段配置是会被继承的。

修改account-email的POM如下：

继承dependencyManagement的account-email POM

<properties>
        <javax.mail.version>1.4.1</javax.mail.version>
        <greenmail.version>1.3.1b</greenmail.version>
    </properties>
    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-core</artifactId>
            </dependency>
            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-beans</artifactId>
            </dependency>
            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-context</artifactId>
            </dependency>
            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-context-support</artifactId>
            </dependency>
            <dependency>
                <groupId>junit</groupId>
                <artifactId>junit</artifactId>
            </dependency>
            <dependency>
                <groupId>javax.mail</groupId>
                <artifactId>mail</artifactId>
                <version>${javax.mail.version}</version>
            </dependency>
            <dependency>
                <groupId>javax.icegreen</groupId>
                <artifactId>greenmail</artifactId>
                <version>${greenmail.version}</version>
                <scope>test</scope>
            </dependency>
        </dependencies>

子模块只需要配置简单的groupId和artifactId就能获得对应的依赖信息，从而引入正确的依赖。

> 这种依赖管理机制似乎不能减少太多的POM配置，但是其好处很大，原因在于在POM中使用dependencyManagement声明依赖能够统一规范项目中依赖的版本，当依赖的版本在父POM中声明之后，子模块在使用依赖的时候就无效声明版本，也就不会发生多个子模块使用依赖版本不一致的情况。这可以降低依赖冲突的几率。

如果在子模块不声明依赖的使用，即使该依赖已经在父POM的dependencyManagement中声明了，也不会产生任何实际的效果。

如果子模块不声明依赖的使用，即使该依赖已经在父POM的dependencyManagement中声明了，也不会产生任何实际的效果，如account-persist的POM。

<properties>
        <dom4j.version>1.6.1</dom4j.version>
    </properties>
    <dependencies>
        <dependency>
            <groupId>dom4j</groupId>
            <artifactId>dom4j</artifactId>
            <version>dom4j.version</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-core</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-beans</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context</artifactId>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
        </dependency>
    </dependencies>

这里没有声明spring-context-support,那么该依赖就不会被引入。这正是dependencyManagement的灵活性所在

> 另外，依赖范围有个import范围，import依赖范围只有在dependencyManagement下才有效果，使用该范围的依赖通常指向一个POM，作用是将目标中的dependencyManagement配置导入到当前POM的dependencyManagement中配置，除了复制配置或者继承这两种方式之外，还可以使用import范围依赖将这一配置导入。  
> 使用import范围依赖导入依赖管理配置

<dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>com.juvenxu.mvnbook.account<groupId>
                <artifactId>account-parent</artifactId>
                <version>1.0-SNAPSHOT</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

注意，上面代码中依赖的type为pom,import依赖范围由于其特殊性，一般都指向打包类型为pom的模块。如果有多个项目，他们使用的依赖版本都是一致的，则可以定义一个dependencyManagement专门管理依赖的POM，然后在各个项目中导入这些依赖管理配置。

## 插件管理 ##

> Maven提供了dependencyManagement元素帮忙管理依赖，类似地，Maven也提供了pluginManagement元素帮忙管理插件。该元素中配置的依赖不会造成实际的插件调用行为，当POM中配置了真正的plugin元素，并且其groupId和artifactId与pluginManagement中配置的插件匹配时，pluginManagement的配置才会影响实际的插件行为。

--------------------

> 前面有如何通过组件去将jar-no-fork目标绑定到verity生命周期阶段，以生成项目源码包。如果一个项目中有很多子模块，并且需要这些模块的源码包，那么很显然，为所有模块重复类似的插件配置不是最好的办法，这时最好的办法是在父POM中使用pluginManagement配置插件，代码如下：

<build>
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-source-plugin</artifactId>
                    <version>2.1.1</version>
                    <executions>
                        <execution>
                            <id>attach-sources</id>
                            <phase>verify</phase>
                            <goals>
                                <goal>jar-no-fork</goal>
                            </goals>
                        </execution>
                    </executions>
                </plugin>
            </plugins>
        </pluginManagement>
    </build>

> 当子模块需要生成源码包的时候，只需要如下简单的配置，代码如下：

<build>
            <plugins>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-source-plugin</artifactId>
                </plugin>
            </plugins>
    </build>

> 子模块声明使用了maven-source-plugin插件，同时又继承了父模块的pluginManagement配置，两者基于groupId和artifactId匹配合并。

--------------------

> 当项目中的多个模块有同样的插件配置时，应当将配置移到父POM的pluginMangement元素中。即使各个模块对于同一插件的具体配置不尽相同，也应当使用父POM的pluginManagement元素同意声明插件的版本。甚至可以要求将所有用到的插件的版本在父POM的pluginManagement中声明，子模块使用插件时不配置版本信息，这么做可以统一项目的插件版本，避免潜在的插件不一致或者不稳定的问题，也更易于维护。

## 聚合与继承的关系 ##

> 多模块中的聚合与继承其实是两个概念，其目的是完全不同的，前者主要是为了方便快速构建项目，后者主要是为了消除重复配置。

对于聚合模块来说，它知道有哪些被聚合的模块，但那些被聚合的子模块不知道这个聚合模块的存在。

> 对于继承关系的父POM来说，它不知道哪些子模块继承于它，但那些子模块都必须知道自己的父POM是什么。

在现有的实际项目中，往往会发现一个POM即是聚合POM，又是父POM，这么做主要是为了方便。一般来说，融合使用聚合与继承也没什么问题，例如可以将account-aggretor和account-parent其POM如下：

<project xmlns="http://maven-apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.juvenxu.mvnbook.account</groupId> <artifactId>account-parent</artifactId> <version>1.0.0-SNAPSHOT</version> <packaging>pom</packaging> <name>Account Parent</name> <modules> <module>account-persist</module> </modules> <properties> <springframework.version>2.5.6</springframework.version> <junit.version>4.7</junit.version> </properties> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> <version>${springframework.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-beans</artifactId> <version>${springframework.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>${springframework.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context-support</artifactId> <version>${springframework.version}</version> </dependency> <dependency> <groupId>junit<groupId> <artifactId>junit</artifactId> <version>${junit.version}</version <scope>test</scope> </dependency> </dependencies> </dependencyManagement> <build> <pluginManagement> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.5</source> <target>1.5</target> </configuration> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-resource-plugin<artifactId> <configuration> <endcoding>UTF-8</encoding> </configuration> </plugin> </plugins> </pluginManagement> </build </project>

可以看到POM的打包方式为pom,它包含了一个modules元素，表示用来聚合account-persist和account-email两个模块，它还包含了properties、dependencyManagement和pluginManagement元素供子模块继承。

## 约定优于配置 ##

Maven默认的源码目录是：src/main/java但是用户也可以自己指定源码目录，如下：

<project>
        <modelVersion>4.0.0</modelVersion>
        <groupId>com.juvenxu.mvnbook<groupId>
        <artifactId>my-project</artifactId>
        <version>1.0</version>
        <build>
            <sourceDirectory>src/java</sourceDirectory>
        </build>
    </project>

上面配置就将源码目录改为src/java而不是默认的src/main/java

任何一个Maven项目都隐式的继承自该POM,这有点类似任何一个Java类都隐式的继承于Object类，因此，大量超级POM的配置都会被所有Maven项目继承，这些配置也就成为了Maven所提倡的约定。

> 对于Maven3,超级POM在文件MAVEN\_HOME/lib/maven-model-builder-x.x.x.jar中的org/apache/maven/model/pom-4.0.0.xml路径下。对于Maven2,超级POM在文件$MAVEN\_HOME/lib/maven-x.x.x-uber.jar中的org/apache/maven/project/pom-4.0.0.xml目录下。

超级POM的内容在Maven2和Maven3中基本一致，分段看一下，见代码：

<repositories>
        <repository>
            <id>central</id>
            <name>Maven Repository Switchboard</name>
            <url>http://repo1.maven.org/maven2</url>
            <layout>default</layout>
            <snapshots>
                <enabled>false</enabled>
            </snapshots>
        </repository>
    </repositories>
    <pluginRepositories>
        <pluginRepository>
            <id>central</id>
            <name>Maven Plugin Repository</name>
            <url>http://repo1.maven.org/maven2</url>
            <layout>default</layout>
            <snapshots>
                <enabled>false</enabled>
            </snapshots>
            <releases>
                <updatePolicy>never</updatePolicy>
            </releases>
        </pluginRepository>
    </pluginRepositories>

超级POM定义了仓库及插件仓库，两者的地址都是为中央仓库[http://repo1.maven.org/maven2][http_repo1.maven.org_maven2]，并且都关闭了SNAPSHOT的支持，这也就解释了为什么Maven默认就可以按需要从中央仓库下载构件。

超级POM中关于项目结构的定义：

<build>
        <directory>${project.basedir}/target<directory>
        <outputDirectory>${project.build.directory}/classes</outputDirectory>
        <finalName>${project.artifactId}-${project.version}</finalName>
        <testOutputDirectory>${project.build.directory}/test-classes</testOutputDirectory>
        <sourceDirectory>${project.basedir}/src/main/java</sourceDirectory>
        <scriptSourceDirectory>src/main/script</scriptSourceDirectory>
        <testSourceDirectory>${project.basedir}/src/test/java</testSourceDirectory>
        <resources>
            <resource>
                <directory>${project.basedir}/src/main/resources</directory>
            </resource>
        </resources>
        <testResources>
            <testResource>
                <directory>${project.basedir}/src/test/resources</directory>
            </testResource>
        </testResources>

> 这里依次定义了项目的主输出目录，主代码输出目录，最终构件的名称格式、测试代码输出格式、主源码目录，脚本源码目录、测试源码目录、主资源目录和测试资源目录。这就是Maven项目结构的约定。

接着，超级POM为核心插件设定版本，代码如下:

<pluginManagement>
        <plugins>
            <plugin>
                <artifactId>maven-antrun-plugin</artifactId>
                <version>1.3</version>
            </plugin>
    
            <plugin>
                <artifactId>maven-assembly-plugin</artifactId>
                <version>2.2-bete-4</version>
            </plugin>
    
            <plugin>
                <artifactId>maven-clean-plugin</artifactId>
                <version>2.3</version>
            </plugin>
    
            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>2.0.2</version>
            </plugin>
            ........
        </plugins>
    </pluginManagement>
    
    </build>

## 反应堆 ##

> 在一个多模块的Maven项目中，反应堆（Reactor）是指所有模块组成的一个构建结构。对于单模块的项目，反应堆就是该模块本身，对于多模块来说，反应堆就包含了各模块之间继承与依赖的关系，从而能够自动计算出合理的模块构建顺序。

例如：

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

以上，构建顺序不一定是顺序去读取POM的顺序，当一个模块依赖于另外一个模块，Maven会先去构建被依赖模块，并且Maven中不允许出现循环依赖的情况，就是，当出现模块A依赖于B,而B又依赖于A的情况时，Maven就会报错。

**裁剪反应堆**

> 一般来说，用户会选择构建整个项目或者选择构建单个的模块，但有些时候，用户会想要仅仅构建完整反应堆中的某些个模块。换句话说，用户需要实时地剪裁反应堆。

Maven提供很多命令行选项支持裁剪反应堆，输入mvn -h可以看到这些选项：

> \-am, –also-make：同时构建所列模块的依赖模块  
> \-amd -also-make-dependents:同时构建依赖于所列模块的模块  
> \-p,–project  
> \-rf -resume-from

默认情况从account-aggregator执行mvn clean install会得到如下完整的反应堆：

[INFO]-----------------------------------------------------
    [INFO]Reactor Build Order:
    [INFO]
    [INFO]Account Aggregator
    [INFO]Account Parent
    [INFO]Account Email
    [INFO]Account Persist
    [INFO]
    [INFO]-----------------------------------------------------

可以使用-pl选项指定构建某几个模块，如运行如下命令：

$ mvn clean install -p account-email,account-persist  
得到的反应堆为:

[INFO]-----------------------------------------------------
    [INFO]Reactor Build Order:
    [INFO]
    [INFO]Account Email
    [INFO]Account Persist
    [INFO]
    [INFO]-----------------------------------------------------

使用-am选项可以同时构建所列模块的依赖模块，例如：

$ mvn clean install -pl account-parent -am  
由于account-email和account-persist都依赖于account-parent，因此会得到如下反应堆：

[INFO]-----------------------------------------------------
    [INFO]Reactor Build Order:
    [INFO]
    [INFO]Account Parent
    [INFO]Account Email
    [INFO]Account Persist
    [INFO]
    [INFO]-----------------------------------------------------

使用-rf选项可以在完整的反应堆构建顺序基础上指定从哪个模块开始构建。例如：

$mvn clean install -rf account-email  
完整的反应堆构建顺序中，account-email位于第三，它之后只有account-persist因此会得到如下的剪裁反应堆：

最后在-pl -am或者-pl -amd的基础上，还能应用-rf参数，以对裁剪后的反应堆再次剪裁,例如：

$ mvn clean install -pl account-parent -amd -rf account-email  
该命令中的-pl和-amd参数会裁剪出一个account-parent、account-email和account-persist的反应堆，在此基础上，-rf参数指定从account-email参数构建。因此会得到如下的反应堆：

在开发过程中，灵活应用上述四个参数，可以帮助我们跳过无须构建的模块，从而加速构建。在项目庞大、规模特别多的时候，这种效果就会异常明显。

[http_repo1.maven.org_maven2]: http://repo1.maven.org/maven2