Maven 相关知识点

    1. Maven的Lifecycle和Scope
    
    （1）Dependency Scope:
        a. compile时，在编译、测试、运行时，都需要jar在classpath中
        b. provided时，在编译、测试时，需要jar在classpath中，而运行时则认为在容器如【tomcat或JDK】会默认提供，所以不需要jar在classpath中
        c. runtime时，只在运行时需要jar在classpath中
        d. test时，只在测试时需要jar在classpath中
        e. system时，maven不会再repository中寻找加载，由开发者指定路径
        f. import时，只对distribution management有用
    （2）Build Lifecycle
        a. 是指一个项目build的过程。maven的Build Lifecycle分为三种，分别为default（处理项目的部署）、clean（处理项目的清理）、site（处理项目的文档生成）。他们都包含不同的lifecycle。
        b. Build Lifecycle是由phases构成的，下面重点介绍default Build Lifecycle几个重要的phase
        *validate 验证项目是否正确以及必须的信息是否可用
        *compile 编译源代码
        *test 测试编译后的代码，即执行单元测试代码
        *package 打包编译后的代码，在target目录下生成package文件
        *integration-test 处理package以便需要时可以部署到集成测试环境
        *verify 检验package是否有效并且达到质量标准
        *install 安装package到本地仓库，方便本地其它项目使用
        *deploy 部署，拷贝最终的package到远程仓库和替他开发这或项目共享，在集成或发布环境完成
            以上的phase是有序的（注意实际两个相邻phase之间还有其他phase被省略，完整phase见lifecycle），下面一个phase的执行必须在上一个phase完成后，若直接以某一个phase为goal，将先执行完它之前的phase，如mvn install，将会先validate、compile、test、package、integration-test、verify最后再执行install phase
     
    （3）Goal
    goal代表一个特定任务
         A goal represents a specific task (finer than a build phase) which contributes to the building and managing of a project.
    如
    mvn package表示打包的任务，通过上面的介绍我们知道，这个任务的执行会先执行package phase之前的phase
    mvn deploy表示部署的任务
    mven clean install则表示先执行clean的phase（包含其他子phase），再执行install的phase。
    
    2.  Parent元素用法
    （1）继承：
        a. 子模块可以继承parent中的配置项，减少每个模块的依赖重复配置，便于版本控制
        b. 配置方法：
        在parent项目的pom.xml中配置
            

<groupId>com.webex.gfc</groupId>
<artifactId>gfc-parent</artifactId>
<version>3.6.3-SNAPSHOT</version>
<packaging>pom</packaging>

        在子项目中配置
            

         <parent>
                <artifactId>gfc-parent</artifactId>
                <groupId>com.webex.gfc</groupId>
                <version>3.6.3-SNAPSHOT</version>
            </parent>

        c. 继承标签<dependencyManagement>：
        在parent的pom中配置 ，这样子模块可以公用parent的依赖版本关系，好处在于各子模块的依赖包版本统一，同时只有使用了该依赖的子模块才会导入标签内依赖包，如：
        parent的pom配置：
      

 <dependencyManagement>
            <dependencies>
                <dependency>
                    <groupId>commons-collections</groupId>
                    <artifactId>commons-collections</artifactId>
                    <version>3.2.2</version>
                      </dependency>
                <dependency>
                    <groupId>commons-lang</groupId>
                    <artifactId>commons-lang</artifactId>
                    <version>2.5</version>
                </dependency>
            </dependencies>
        <dependencyManagement>

        子项目pom配置：
      

 <dependency>
          <groupId>commons-collections</groupId>
            <artifactId>commons-collections</artifactId>
        </dependency>

        这样子项目就只会加载一个依赖包，同时从parent获取version
        
        d. 继承标签<pluginManagement>类似<dependencyManagement>
      

 <pluginManagement>
            <plugins>
                <plugin>
                    <groupId></groupId>
                    <artifactId></artifactId>
                    <version></version>
                    <executions></executions>
                </plugin>
            </plugins>
        <pluginManagement>

        
    （2）聚合（aggregation）:
        简化构建过程，统一构建各模块
    3. 标签<distributionManagement>:
      

 <distributionManagement>
            <repository>
                <id>clops-releases</id>
                <name>ClopsHF Release Repository</name>
                <url>http://mrepo-cmse.qa.webex.com/nexus/content/repositories/releases/</url>
            </repository>
            <snapshotRepository>
                <id>clops-snapshots</id>
                <name>ClopsHF Snapshot Repository</name>
                <url>http://mrepo-cmse.qa.webex.com/nexus/content/repositories/snapshots/</url>
            </snapshotRepository>
            <site>
                <id>teo-repo1</id>
                <url>
                    ftp://nexus:nexus@10.224.54.115/app/sonatype-work/sites/${project.artifactId}
                </url>
            </site>
        </distributionManagement>

        maven会根据模块的版本号(pom文档中的version)中是否带有-SNAPSHOT来判断是快照版本还是正式版本。如果是快照版本，那么在mvn deploy时会自动发布到快照版本库中，而使用快照版本的模块，在不更改版本号的情况下，直接编译打包时，maven会自动从镜像服务器上下载最新的快照版本。如果是正式发布版本，那么在mvn deploy时会自动发布到正式版本库中，而使用正式版本的模块，在不更改版本号的情况下，编译打包时如果本地已经存在该版本的模块则不会主动去镜像服务器上下载。所以，我们在开发阶段，可以将公用库的版本设置为快照版本，而被依赖组件则引用快照版本进行开发，在公用库的快照版本更新后，我们也不需要修改pom文档提示版本号来下载新的版本，直接mvn执行相关编译、打包命令即可重新下载最新的快照库了，从而也方便了我们开发
    
    4. <build>标签
    （1）基本元素：BaseBuild 
      1）defaultGoal 
执行 mvn 命令时，如果没有指定目标，指定使用的默认目标。 在命令行中执行 mvn，则相当于执行： mvn install 
              2）directory 
                     目标文件的存放目录，默认在 ${basedir}/target 目录 
              3）finalName 
                     目标文件的名称，默认情况为 ${artifactId}-${version} 
              4）filter 
                     定义 *.properties 文件，包含一个 properties 列表，  该列表会应用到支持 filter 的 resources 中。 也就是说，定义在 filter 的文件中的 name = value 键值对，会在build时代替 ${name} 值应用到 resources 中。   maven的默认filter文件夹为 ${basedir}/src/main/filters 

        （2）Resources配置 - 1 
                 用于包含或者排除某些资源文件。 
                 说明：资源通常不是源代码（也可以是），它们一般不被编译，例如：.xml 文件， .properties文件等
    
  （3）plugins配置 
                  用于指定使用的插件 

         1）GAV (groupId, artifactId, version) 
                      指定插件的标准坐标 
                2）extensions 
                      是否加载plugin的extensions，默认为false 
                3）inherited 
                      true/false，这个plugin是否应用到该pom的孩子pom，默认为true 
                4）configuration 
                      配置该plugin期望得到的properties 
                5）dependencies 
                      作为plugin的依赖 
                6）executions 
                      plugin可以有多个目标，每一个目标都可以有一个分开的配置，可以将一个plugin绑定到不同的阶段 
                      假如绑定antrun：run目标到verify阶段 

（4）pluginManagement配置