Maven的pom文件那些事

摘要：文件项目隶属的实际项目名实际项目中的一个项目模块名称版本号当前项目打包的方式，默认为以上的配置会获得一个格式的包用于定义构建输出的一些附属的构建。

org.son.nexus//项目隶属的实际项目名
nexus-indexer//实际项目中的一个maven项目模块名称
2.0.0//版本号
jar//当前maven项目打包的方式，默认为jar

以上的配置会获得一个-.格式的包//nexus-indexer-2.0.0.jar

jdk7//用于定义构建输出的一些附属的构建。classifier是不能直接定义的，只能存在附加的构件（插件）时，才能（必须）添加。在包名上也会有所提现（nexus-indexer-2.0.0-javadoc.jar）

jar包在仓库中的路径规律：groupId/artifactId/version/groupId-version

groupId、artifactId、version为基本坐标

type为依赖类型，默认为jar

scope为依赖范围

compile：编译，测试，运行三种classpath都有效
test：只对测试有效
provided：编译和测试有效
runtime：测试和运行有效
system：系统依赖，依赖的包是从计算机本地导入，与systemPath配合使用
​    ${java.home}/lib/rt.jar
​    system

传递性依赖

maven默认就是支持的。

什么是传递性依赖？

比如：现在要导入A.jar包，但A.jar有依赖于B.jar，在maven中就会默认导入B.jar，而不需要手动去导入。

scope最好设为compile

传递性依赖存在一个问题：工程中存在两个jar分别依赖的是B.jar的不同版本jar包，就会出现错误。

optional：可选依赖，true 不会传递，false会传递（默认）

mysql
mysql-connector-java
5.1.10
true

当其他项目C依赖B项目时，mysql-connector-java的依赖不会发生传递给C

优点：

减少冲突，不用的功能不传递

一个jar应该只有 一个职责原则

用于替换某个 依赖中的依赖包作用

    
        com.juv
        project-B
        1.0.0
        
            //可以有多个
                com.juv
                project-C
            
        
    
    
        com.juv
        project-B
        1.1.0
    

该例子的意思：不想使用project-B中版本的project-C依赖包，而将其环卫1.1.0的project-C包

场景：存在一群版本号一致的依赖，想通过一个统一的配置，将其统一配置和修改

    2.5.6

调用方式

${spring}

修改工程中的pom文件

    ....
    
           //发布版本构件的仓库
              //远程仓库的唯一标识
               //自定义
               //该仓库地址
        
         //快照版本的设置
            
            
               
        
    
    ....

如果需要认证，则在setting.xml文件中增加一个元素进行配置

在配置完成后，执行mvn clean deploy 就会根据当前版本类型，发布到相应的仓库中

快照版本

快照不是正式版本，当设为带有SNAPSHOT的version时，即为快照版本，每次向仓库部署是，会自动打上时间戳，其他引用快照相同版本时会自动下载更新

例如：2.1-SNAPSHOT时，则会下载2.1-20091214之类的构件

在maven本地仓库的groupId/artifactId/version文件路径下会存在maven-metadata.xml文件，会记录版本信息

  com.android.support
  multidex
  1.0.0
  
    
      1.0.0
      1.0.1
    
    20141209014044
  

maven的生命周期是抽象的，其实际行为都是由插件来完成的。

maven的生命周期是不做任何实际工作，实际任务都由插件完成。

maven具有三个独立的生命周期：clean、defeat、site

1、clean生命周期：清理项目，包含三个phase。

1）pre-clean：执行清理前需要完成的工作
2）clean：清理上一次构建生成的文件
3）post-clean：执行清理后需要完成的工作

2、default生命周期：构建项目，重要的phase如下。

1）validate：验证工程是否正确，所有需要的资源是否可用。
2）compile：编译项目的源代码。  
3）test：使用合适的单元测试框架来测试已编译的源代码。这些测试不需要已打包和布署。
4）Package：把已编译的代码打包成可发布的格式，比如jar。
5）integration-test：如有需要，将包处理和发布到一个能够进行集成测试的环境。
6）verify：运行所有检查，验证包是否有效且达到质量标准。
7）install：把包安装到maven本地仓库，可以被其他工程作为依赖来使用。
8）Deploy：在集成或者发布环境下执行，将最终版本的包拷贝到远程的repository，使得其他的开发者或者工程可以共享。

3、site生命周期：建立和发布项目站点，phase如下

1）pre-site：生成项目站点之前需要完成的工作
2）site：生成项目站点文档
3）post-site：生成项目站点之后需要完成的工作
4）site-deploy：将项目站点发布到服务器

命令行输入：$mvn clean 其实调用的是clean生命周期的clean阶段，执行了pre-clean和clean

而这些命令其实是由插件提供功能的。

    
        
            org.apache.maven.plugins//maven官方，官方的可以省略该标签
            maven-source-plugin//插件
            2.1.1//没有version时，会默认下载最新的release版本
          //配置执行n个任务
                
                       attach-sources//可以任意
                       verify//绑定到verify生命周期，在此时才会起作用
                    
                           jar-no-fork//启用该插件的jar-no-fork功能
                    
                
            
        
    

因为一个插件可能存在多个功能，但我们并不一定所有的功能都需要，所以设定goal标签，表示我们要实现的功能。

命令行配置：$mvn install -Dt 插件相关参数 //适用于当每次运行时，这个插件的配置都会变的情况

pom中全局配置：

    
        
            maven-compiler-plugin
            3.1
            
              1.7  //jdk1.7
              1.7 //编译后jdk1.7
            
        
    

意义：一次构建所有想要构建的项目

    4.0.0
    org.son.nexus
    nexus-indexer
    2.0.0
    pom//本身也是一个maven工程
    
          account-email//想要构建的项目，这里写的是当前pom文件下的相对路径地址
        account-persilist
    

聚合pom文件的packaging标签一定要是pom，其工程就只是一个pom文件，没有其他的实现代码

一般来说模块处的目录名应与其artifactId一致

聚合模块与其他模块的目录结构并非一定要父子关系

父pom

    4.0.0
    org.son.nexus
    nexus-indexer
    2.0.0
    pom//本身也是一个maven工程
     
        
            com.juv
            project-B
            1.0.0
            
                
                    com.juv
                    project-C
                
            
        
        
            com.juv
            project-B
            1.1.0
        
    

父pom的packaging也是pom

子pom

    4.0.0
    org.son.nexus
    nexus-B
    2.0.0
    jar
    
        org.son.nexus
        nexus-C
        1.0.0-SNAPSHOT
        ../pom.xml//相对路径
    
    

子pom的packaging则不一定要是pom，但一定有parent标签

子类的groupId和version也可以继承与父pom文件

作用：当子类不需要父pom中的某些依赖的时，就可以使用。

父pom

    
        
            spring-core
            org.springframework
            3.1.1.RELEASE
        
     

被标签所包裹的依赖是不会主动被加载进入子pom中，只有子pom中显式再次声明的时候才会被依赖

子pom

    
        spring-core
        org.springframework
    

可以省略version等其他配置，因为父pom中已经配置过了

若想获取父pom中所有的dependencyManagement中的构件配置，则在子pom中如下配置

    
        
            account-parent
            com.juvenxu.accout
            3.1.1.RELEASE
            pom
            import
        
     

配置父pom的一些信息

父pom中的插件不想在子类中默认使用

跟依赖管理一样，被包裹的插件配置不会被子pom主动获取，只有当子pom中声明了该插件的groupId和artifactId后，才会被继承

一个pom文件既可以是聚合也可以是父pom

在聚合构建时，构件模块的先后顺序的排列。

按书写的先后顺序进行构建

如果同一个项目中存在多个模块相互依赖时候，version和groupId可以使用${project.groupId}（当前模块的groupId）和${project.verison}，这样就不用不断的更改了。

标签用来确定最终包名

以上です(Ending)

ありがどう(Thank You)