maven2学习总结（4.生命周期和使用Maven进行编译）

生命周期

软件项目一般遵循一个相似的、熟悉的过程：准备、编写代码、测试、打包、安装。Maven适应各种不同的项目的路线称为构建生命周期。在Maven中，构建生命周期由一系列阶段组成，每个阶段可以实施一个或者多个和该阶段相关的行动（Action），或目标（goal）。例如，编译阶段调用一组目标（goal）去编译类。

在Maven中的标准构建生命周期中，你每天都会执行特定的阶段的工作。例如，你告诉Maven你打算去编译或测试，或打包，或安装。这些你需要去执行的Action，被高水平的启动并且Maven在幕后处理了细节的操作。需要去注意到重要一点是，生命周期中的每个阶段都将被执行，直至包括你指定的阶段。如果你告诉Maven去编译，那么校验、初始化、生成源文件、处理源文件、生成资源以及编译阶段都将被执行。

常规的构建生命周期包括很多阶段，这些可以被看作是扩展点。当你需要添加一些功能到生命周期中去，你可以通过插件来完成。Maven插件提供了可重用的构建逻辑，可以被插入标准的构建流程。任何时候你想自定义你的项目的构建过程，要么你可以使用一个已有的插件，或者创建一个定制的插件。查看2.7章使用Maven插件来获得定制Maven构建的示例。

完整的maven生命周期：

生命周期 阶段描述

validate	验证项目是否正确，以及所有为了完整构建必要的信息是否可用
generate-sources	生成所有需要包含在编译过程中的源代码
process-sources	处理源代码，比如过滤一些值
generate-resources	生成所有需要包含在打包过程中的资源文件
process-resources	复制并处理资源文件至目标目录，准备打包
compile	编译项目的源代码
process-classes	后处理编译生成的文件，例如对Java类进行字节码增强（bytecode enhancement）
generate-test-sources	生成所有包含在测试编译过程中的测试源码
process-test-sources	处理测试源码，比如过滤一些值
generate-test-resources	生成测试需要的资源文件
process-test-resources	复制并处理测试资源文件至测试目标目录
test-compile	编译测试源码至测试目标目录
test	使用合适的单元测试框架运行测试。这些测试应该不需要代码被打包或发布
prepare-package	在真正的打包之前，执行一些准备打包必要的操作。这通常会产生一个包的展开的处理过的版本（将会在Maven 2.1+中实现）
package	将编译好的代码打包成可分发的格式，如JAR，WAR，或者EAR
pre-integration-test	执行一些在集成测试运行之前需要的动作。如建立集成测试需要的环境
integration-test	如果有必要的话，处理包并发布至集成测试可以运行的环境
post-integration-test	执行一些在集成测试运行之后需要的动作。如清理集成测试环境。
verify	执行所有检查，验证包是有效的，符合质量规范
install	安装包至本地仓库，以备本地的其它项目作为依赖使用
deploy	复制最终的包至远程仓库，共享给其它开发人员和项目（通常和一次正式的发布相关）

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/abigfrog/archive/2008/10/22/3123776.aspx

使用Maven进行编译

正如在介绍的文章中所提到的，要完成预定的任务，你是在一个很高的层次，使用声明的方式来告知Maven如何做的。在你开始编译前，注意在这个简单命令的背后所显示的四个Maven基础工作步骤：

•通过配置进行约定
•重用构建逻辑
•声明式执行
•有序的依赖组织
这些准则存在于Maven的方方面面，但下面对简单编译命令的分析，向你展示了这四个准则的工作情况，并明确它在简化开发中所起的重要作用。

切换大<my-app>目录，<my-app>是my-app项目的基础目录，使用${basedir}表示。下面，你将使用如下命令编译你的源代码：

C:\mvnbook\my-app> mvn compile

执行完成后，你将得到和如下类似的输出：

1.[INFO--------------------------------------------------------------------
2.[INFO] Building Maven Quick Start Archetype
3.[INFO] task-segment: [compile]
4.[INFO]-------------------------------------------------------------------
5.[INFO] artifact org.apache.maven.plugins:maven-resources-plugin: checking for
6.updates from central
7....
8.[INFO] artifact org.apache.maven.plugins:maven-compiler-plugin: checking for
9.updates from central
10....
11.[INFO] [resources:resources]
12....
13.[INFO] [compiler:compile]
14.Compiling 1 source file to c:\mvnbook\my-app\target\classes
15.[INFO]-------------------------------------------------------------------
16.[INFO] BUILD SUCCESSFUL
17.[INFO]-------------------------------------------------------------------
18.[INFO] Total time: 3 minutes 54 seconds
19.[INFO] Finished at: Fri Sep 23 15:48:34 GMT-05:00 2005
20.[INFO] Final Memory: 2M/6M
21.[INFO]-------------------------------------------------------------------
 

现在让我们分析下究竟发生了什么，并且看下在看起来很简单的命令下，之前提到的四个基础工作是如何进行的。

Maven是如何知道从哪里找到要编译的源文件？并且Maven如何知道将编译好的类文件放到哪里？这里就是由Mave基础工作之一“通过配置进行约定”所解决的问题。一般情况下，源文件放在src/main/java路径下，这种默认设置（虽然在上面的POM文件中并没看到）是从Super POM继承来的。即使最简单的POM也知道源文件的默认位置。这意味着如果你的源文件存在于默认位置的话，你不需要在POM里面明确设置这些位置。当然，你也可以覆盖默认的位置，但并不推荐这样做。这同样也适用于编译后的类文件的默认位置是target/classes。

究竟是什么编译了应用程序的源文件？这就是Maven的基础工作之二——“重用构建逻辑”的功劳了。默认设置里的标准编译器插件，被用来编译应用程序的源文件。同样的构建逻辑可以在任务数量的项目上通用。

虽然你现在知道了编译器插件被用来编译应用程序的源文件，那么Maven是如何决定去使用这个编译器的那？你可能猜测存在一个后台进程映射了一个简单命令到某个插件。实际上，存在一个名为默认的build life cycle。

那么，现在你知道了Maven如何去找到应用程序源代码，Maven使用什么去编译源代码，并且如何去调用编译器插件。下一个问题就是，Maven从哪里得到的这个编译器插件？毕竟，在Maven安装过程中，你看不到这个编译器插件，因为它不随Maven安装包一起发布，相反，Maven会在用到他们的时候再下载。

当你首次执行这个命令（或其他命令）的时候，Maven会下载所有插件以及相关的文件。如果从一个简洁的Maven安装开始，可能需要一段时间（对于前面提到的来说，宽带下载的话可能需要4分钟左右）。下次你再执行同一个命令的时候，因为Maven已经有了它所需要的，就不会再需要下载什么了，因此，Maven会比以前更快的执行此命令。

从输出你可以看出来，编译后的类文件被放在了target/classes中，这是在默认设置中定义的。如果你是一个仔细的观察者的话，你会发现使用一般的约定会让你的POM非常小，没有了告知Maven到哪里去找源代码，或输出文件放在哪的必要。使用默认的配置，你往往可以事半功倍。