Maven学习（三）

maven相关概念

maven坐标

Maven世界拥有大量构建，当我们需要引用依赖包是，需要用一个用来唯一标识去确定唯一的一个构建。如果拥有了统一规范，就可以把查找工作交给机器。

类似于空间找点的坐标一样，maven坐标应运而生，为各种构件引入了秩序：

• groupId：组织标识名（简单理解成 包名）
• artifactId：项目名称
• version：项目的当前版本
• packaging：项目的打包方式，最为常见的jar和war两种（项目中继承的话，为pom）
• classifier: 该元素用来帮助定义构建输出的一些附属构件（不能被直接定义）

注：groupId、artifactId、version、packaging是必须定义的，classifier是不能被直接定义的，因为附属构件不是项目直接默认生成的，而是由附加的插件帮助生成的。

依赖项管理

依赖性管理，在pom.xml文件中<dependency></dependency>中

依赖项示例

pom.xml文件中：

<!--项目要使用到junit的jar包，所以在这里添加junit的jar包的依赖-->
    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.9</version>
            <scope>test</scope>
        </dependency>

<!--项目要使用到ConsoleHello的jar包，在这里添加ConsoleHello的jar包的依赖-->
    <dependency>
        <groupId>com.lsk.mavenCode</groupId>
        <artifactId>ConsoleHello</artifactId>
        <version>SNAPSHOT-0.0.1</version>
        <scope>compile</scope>
    </dependency>
    </dependencies>

依赖范围

依赖范围<scope></scope>用来控制依赖和编译、测试、运行的classpath的关系。

主要的是三种依赖关系如下：
　　1.compile： 默认编译依赖范围。->对于编译、测试、运行三种classpath都有效
　　2.test：测试依赖范围。->只对于测试classpath有效
　　3.provided：已提供依赖范围。->对于编译、测试的classpath都有效，但对于运行无效。因为由容器已经提供，例:servlet-api
　　4.runtime: 运行时提供。(如:JDBC驱动)

依赖传递

若A依赖B，B依赖C，则A也依赖于C（A对于C为间接依赖）

仓库管理

仓库用来统一存储所有Maven共享构建的位置，

根据maven坐标，目录方式： groupId/artifactId/version/artifactId-version.packaging 就可以唯一确定一个构建。

每个用户只有一个本地仓库，默认是在${user.home}/.m2/repository/，${user.home}代表的是用户目录，例：

1、Maven默认的远程仓库：URL：http://search.maven.org/，我们需要引用外部的包时，可以从上面查到相关的GroupId、版本号等信息；

2、私服：是一种特殊的远程仓库，架设在局域网内的仓库（一般公司内部都会有一个自己的私服）

生命周期

Maven有三种相互独立的标准生命周期，这三种生命周期分别是：

1、Clean Lifecycle(清洁生命周期):在进行真正的构建之前进行一些清理工作。
    2、Default<Build> Lifecycle(默认<或生成>生命周期 ):构建的核心部分：编译、测试、打包、部署等等。
    3、Site Lifecycle(网站生命周期 ) 生成项目报告、站点、发布站点。

说明下：它们是相互独立的，你可以仅仅调用clean来清理工作目录、仅仅调用site来生成站点。当然也可以组合命令直接运行 mvn clean install site 运行所有这三种生命周期。

每种生命周期都由一组阶段(Phase)组成。我们平时输入的命令总会对应于一个特定的阶段（真正执行时，包含此生命周期中的这个阶段及其之前的所有阶段），比如：

运行mvn clean ，clean是Clean Lifecycle的一个阶段。他还有pre-clean阶段、clean阶段、post-clean阶段。

"mvn clean" 中的clean就是上面的clean及其同一种生命周期前的所有阶段。

Clean Lifecycle

　 1.pre-clean 执行一些需要在clean之前完成的工作
    2.clean 移除所有上一次构建生成的文件
    3.post-clean 执行一些需要在clean之后立刻完成的工作

Default<Build> Lifecycle

1.pre-site 执行一些需要在生成站点文档之前完成的工作
    2.site 生成项目的站点文档
    3.post-site 执行一些需要在生成站点文档之后完成的工作，并且为部署做准备
    4.site-deploy 将生成的站点文档部署到特定的服务器上

这里经常用到的是site阶段和site-deploy阶段，用以生成和发布Maven站点，这可是Maven相当强大的功能，Manager比较喜欢，文档及统计数据自动生成。

Default<Build> Lifecycle

Default<Build> Lifecycle是Maven生命周期中最重要的一个，绝大部分工作都发生在这个生命周期中，用于构建应用程序。它有以下 23 个阶段。

生命周期阶段	描述
validate	验证项目是否正确，并且所有必要的信息可用于完成构建过程
initialize	建立初始化状态，例如设置属性
generate-sources	产生任何的源代码包含在编译阶段
process-sources	处理源代码，例如，过滤器值
generate-resources	包含在包中产生的资源
process-resources	复制和处理资源到目标目录，准备打包阶段
compile	编译该项目的源代码
process-classes	从编译生成的文件提交处理，例如：Java类的字节码增强/优化
generate-test-sources	生成任何测试的源代码包含在编译阶段
process-test-sources	处理测试源代码，例如，过滤器任何值
test-compile	编译测试源代码到测试目标目录
process-test-classes	处理测试代码文件编译生成的文件
test	运行测试使用合适的单元测试框架（JUnit）
prepare-package	执行必要的任何操作的实际打包之前准备一个包
package	提取编译后的代码，并在其分发格式打包，如JAR，WAR或EAR文件
pre-integration-test	完成执行集成测试之前所需操作。例如，设置所需的环境
integration-test	处理并在必要时部署软件包到集成测试可以运行的环境
pre-integration-test	完成集成测试已全部执行后所需操作。例如，清理环境
verify	运行任何检查，验证包是有效的，符合质量审核规定
install	将包安装到本地存储库，它可以用作当地其他项目的依赖
deploy	复制最终的包到远程仓库与其他开发者和项目共享

有涉及到Maven 生命周期值得一提几个重要概念：

• 当一个阶段是通过 Maven命令调用，例如：mvn compile，只有阶段到达并包括这个阶段才会被执行。

• 不同的 Maven 目标绑定到 Maven生命周期的不同阶段这是这取决于包类型(JAR/WAR/EAR)。

maven插件

maven插件机制是完全依赖Maven的生命周期的。

Maven 提供以下两种类型插件：

类型	描述
构建插件	在生成过程中执行，并在 pom.xml 中的<build/> 元素进行配置
报告插件	在网站生成期间执行，在 pom.xml 中的 <reporting/> 元素进行配置

以下是一些常见的插件列表：

插件	描述
clean	编译后的清理目标，删除目标目录
compiler	编译 Java 源文件
surefile	运行JUnit单元测试，创建测试报告
jar	从当前项目构建 JAR 文件
war	从当前项目构建 WAR 文件
javadoc	产生用于该项目的 Javadoc
antrun	从构建所述的任何阶段运行一组 Ant 任务

1. Maven的核心仅仅定义了抽象的生命周期，具体任务是交由插件完成。
2. 每个插件都可以实现多个功能，每个功能就是一个插件目标。
3. Maven的生命周期与插件目标相互绑定，以完成某个具体的构建任务，例如compile就是插件maven-compiler-plugin的一个插件目标。

参考：

http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

http://www.yiibai.com/maven/maven_plugins.html

http://blog.csdn.net/wanghantong/article/details/36427165