Apache Maven（二）：构建生命周期

 

Maven 约定的目录结构

我要遵循Maven已经约定好的目录结构，才能让maven在自动构建过程中找到对应的资源进行构建处理。以下是maven约定的目录结构：

项目名称				
|-- pom.xml				:Maven工程的核心配置文件
|-- src					
    |-- main				:主程序
    |   |-- java			:JAVA源文件
    |   |-- resources			:框架或其他工具配置文件
    |-- test				:测试程序
        |-- java			:JAVA源文件
        |-- resources			:框架或其他工具配置文件

是我们只需要按照以上的目录结构进行存放文件，maven就可以自动找到对应文件进行构建处理。除了以上以下目录外，项目目录下可能还会存在README.txt，LICENSE.txt，.get，.svn，target等等目录或文件。

Maven 构建生命周期

Maven基于构建生命周期的核心概念。这意味着构建项目的过程已被明确定义。对于构建项目的人来说，这意味着只需要学习一小组命令和确保POM能得到想要的结果，就能构建任何Maven项目。

Maven有三种内置构建生命周期： default，clean 和 site。

• default： 生命周期处理项目的部署（后面主讲部分）；
• clean ： 生命周期清理项目；
• site ： 生命周期处理站点文档的创建

默认生命周期（项目部署）包含以下几个阶段：

• validate： 验证项目是否正确，并提供所有有用的必要信息。
• compile： 编译项目的源代码。
• test： 使用合适的单元测试框架测试编译后的源代码。
• package： 获取编译后的代码，并将其打包成可发布的格式，比如JAR。
• verify： 对集成测试结果进行检查，以确保项目符合质量标准。
• install： 将软件包安装到本地仓库中，用作本地其他项目的依赖项。
• deploy： 在构建环境中完成，将最终包复制到远程仓库以与其它开发人员和项目共享。

这些生命周期阶段将按照顺序执行以完成默认的生命周期。这意味着当使用默认生命周期时，Maven先验证项目，然后编译源码，针对测试运行这些代码，打包成二进制文件（例如jar），运行集成测试包，验证集成测试，将经过验证的软件包安装到本地仓库，然后将骂安装软件部署到远程仓库，依次按照顺序执行。

在开发环境中，使用以下命令来构建项目并将其安装到本地仓库中：

mvn install

在执行 install 命令之前，此命令会按照默认生命周期阶段的执行顺序，先执行（validate、compile、package 等命令），只需按照默认周期的最后构建命令install，就可完成此周期。

在构建环境中，可以使用如下命令执行清理构建并且将项目部署到远程仓库中。

mvn clean deploy

同一个命令可用于多模块场景（即具有一个或多个子项目的项目）。Maven遍历每一个项目并执行clean，然后执行deploy（包括默认生命周期所有deploy之前的步骤）。

构建项目由插件目的组成

然而，尽管构建阶段负责构建生命周期的具体步骤，但是履行这些责任的方式可能会有所不同。这是通过声明插件目标绑定到这些构建阶段来完成的。

插件目标代表了一个特定的任务（比构建阶段更精细），有助于项目的构建和管理。它可以绑定到零或更多的构建阶段。不受任何构建阶段限制，可以通过直接调用在构建生命周期之外执行。执行顺序取决于调用目标和构建阶段的顺序，例如以下命令。该命令的clean 和 package 是构建阶段，而dependency:copy-dependencies 是一个插件目标。

mvn clean dependency:copy-dependencies package

如果执行此命令操作，则首先执行clean阶段（意味着执行clean生命周期之前的操作和clean本身），然后执行dependency:copy-dependencies 插件目标。最后执行package阶段（以及默认生命周期所有之前的阶段）。

通常用连字符（pre-*，post-* 或 process-*）命名的阶段不会直接从命令调用。这些阶段对构建进行排序，产生在构建之外无用的中间结果。

参考生命周期

以下列出了 default，clean 和 site 生命周期的所有构建阶段。它们按给定指定点的顺序执行。

• clean 的生命周期：
  • pre-clean： 执行实际项目清理前所需要的流程。
  • clean： 删除以前版本生成的文件。
  • post-clean： 执行完成项目清理所需要的过程。
• default 的生命周期：
  • validate： 验证项目是否正确，并提供所有必要的信息。
  • initialize： 初始化构建状态，例如设置属性或创建目录。
  • generate-sources： 生成包含在编译中的任何源代码。
  • process-sources： 处理源代码，例如过滤一些值。
  • generate-resources： 生成包含在包中的资源。
  • process-resources： 将资源复制并处理到目标目录中，准备打包。
  • compile： 编译项目的源代码。
  • process-classes： 处理从编译后生成的文件，例如在Java类上进行字节码增强。
  • generate-test-sources： 生成包含在编译中的一些测试源代码。 
  • process-test-sources： 处理测试源代码，例如过滤一些值。 
  • generate-test-resources： 创建测试资源文件。 
  • process-test-resources： 将资源复制并处理到测试目标目录中。 
  • test-compile： 将测试源代码编译到测试目标目录中。 
  • process-test-classes： 从测试编译后处理生成的文件，例如在Java类上进行字节码增强 
  • test： 使用合适的单元测试框架运行测试。这些测试不应该要求打包或部署代码。 
  • prepare-package： 在实际打包之前执行一些必要的准备打包的操作。这通常会导致软件包的解压缩。
  • package： 接受编译的代码并将其打包为可发布的格式，例如JAR。
  • pre-integration-test： 在集成测试执行之前执行所需的操作。这可能涉及诸如设置所需环境等事情。 
  • integration-test： 如果需要，可将程序包处理并部署到可运行集成测试的环境中。 
  • post-integration-test： 执行集成测试后执行所需的操作。这可能包括清理环境。 
  • verify： 运行一些检查来验证包是否有效并且符合质量标准。 
  • install： 将软件包安装到本地存储库中，作为本地其他项目的依赖项。 
  • deploy： 在集成或发行版环境中完成，将最终包复制到远程存储库，以便与其他开发人员和项目共享。 
• site 的生命周期：
  • pre-site： 执行实际项目站点生成之前所需的流程。
  • site： 生成项目的网站文档。
  • post-site： 执行完成网站生成所需的流程，并为网站部署做好准备。
  • site-deploy： 将生成的网站文档部署到指定的Web服务器。