Question

在本章的前面几节中我们谈到了生命周期，所以到目前为止，你应该至少掌握 Maven 的构建生命周期中包含编译、测试、打包、安装阶段。在例 12-3 中，我们将 hbm2ddl 目标附加到类处理（process-classes）阶段，同时指出这个阶段紧跟在编译阶段之后。如果所有这些看起来让你感到一头雾水，不要担心，我们将会简单地解释生命周期中的各个阶段和它们的执行顺序。当从命令行运行 Maven 时，需要选择指定某个阶段的名称，或者显式地执行一个插件目标。当指定了一个阶段时，Maven 将执行它的生命周期中直到该阶段之前的所有阶段（包括这个指定的阶段）。在 Maven 处理其构建生命周期时，它会触发附加到当前阶段上的插件的目标。另一方面，如果显式地请求一个插件目标，则 Maven 将只执行那个单独的插件目标。

以下列举了 Maven 的所有生命周期阶段，而且按它们发生的顺序进行排序。对于我们的示例来说比较重要的阶段，会解释得细致些；而对于其他不重要的阶段，则将它们组合起来以节省空间：

validate（验证）

验证 POM。

generate-sources（生成源代码）

生成任何源代码。Hibernate3 插件有一个 hbm2java 目标，可以根据基于 XML 的映射而生成 Java 源代码（就像我们在前几章中做的那样）。如果我们想为映射生成 Java 源代码，则可以将 hbm2java 附加到这个阶段。

process-sources、generate-resources、process-resources（处理源文件、生成资源、处理资源）

除了生成源代码，还需要处理源代码生成的输出、生成资源文件（例如 properties 文件、图片、声音以及程序包的其他非代码元素）以及处理资源文件。

compile（编译）

编译器插件运行编译目标，对编译源代码根目录下的所有源代码进行编译。插件可以在编译源代码根目录中添加新的目录，例如 Hibernate3 插件的 hbm2java 目标就会根据.hbm.xml 文件生成源代码，并将生成的源代码放到 target/generated-source 目录中。Hibernate3 插件接着再将 target/generated-source 目录添加到编译源代码根目录，以便在编译时可以包含新生成的文件。

process-classes（后处理编译生成的类）

该阶段对编译的结果进行后期处理（post-processes）。我们已经将 hbm2ddl 目标挂到了类的后期处理任务上，因为需要对 hbm2ddl 任务进行配置，才可以利用对象模型中的标注，将它们编译为模型类文件。Hibernate3 插件被配置为需要对生成的字节码进行搜索，以查找出现的"@Entity"标注。因为只有先编译好了模型类，才可以进行这样的扫描，所以我们将这个目标挂到了编译阶段之后的处理阶段。

generate-test-sources、process-test-sources、generate-test-resources、process-test-resources

这几个阶段与从 generate-sources 到 generate-resources 的几个阶段类似，可以生成单元测试及其需要的任何资源。

test-compile（编译测试源码至测试目标目录）

使用 testCompile 目标，再次调用 Compiler 插件来编译测试源代码。对于我们的示例来说，这个它只是编译 src/test/java 目录中的一个简单的类。testCompile 目标会编译测试源代码根目录中的所有源代码。再说一次，这并不是简单地对 src/test/java 中的所有代码进行编译，因为在前面 4 个生命周期阶段中，插件都有机会生成单元测试的源代码（在测试源代码根目录中添加目录）。

test（测试）

Surefire 插件扫描 test-compile 阶段生成的继承自 JUnit 的 TestCase 的类，并使用 JUnit 执行这些单元测试（也可以运行 TestNG 测试）。

prepare-package（准备打包）

在真正将项目打包以前，执行一些准备处理。提供与此相关的目标。

package（打包）

对于我们的示例项目来说，最终只需要生成一个 JAR 文件。jar 打包的默认行为就是创建一个名为${artifactId}-${version}.jar 的文件。如果需要的话，可以自定义这个文件名称。不过，如果可能的话，尽可能避免对 Maven 进行定制，将是更好的做法。

pre-integration-test、integration-test、post-integration-test（预集成测试、集成测试、集成测试后期）

单元测试通常不需要连接到数据库，事实上，在单元测试中连接数据库的做法也让人感觉有些古怪（我将其称为功能或集成测试）。如果你需要执行一系列集成测试，可以使用这 3 个阶段来定义相关的目标。

verify（验证）

可以为验证阶段定义一些用于检查生成的输出是否符合质量规范的目标。

install（安装）

在我们的项目中，安装阶段只是将生成的 artifact 复制到～/.m2/repository/${groupId}/${artifactId}/${version}/${artifactId}-${version}.jar 文件中。如果你正在创建一套复杂的交叉依赖的项目（也就是说，项目 A 定义了对一个具体的库的依赖，而项目 B 也需要依赖这个库），那么项目 B 就可以用 groupId、artifactId 以及 version（版本）来定义一个对项目 A 的依赖，当 Maven 在构建项目 B 时，会尝试在本地仓库中解析项目 A 的 artifact。通过将制品也安装到本地仓库中，install 阶段就可以支持这一功能。

deploy（部署）

用于将项目的制品、网站、报告发布到一个外部的仓库中。项目也可以利用这个阶段将各种制品发布到一个远程 Maven 仓库。远程 Maven 仓库可以是公共的或私有的 Maven 仓库，或者是企业内部的 Maven 仓库。