自动化构建工具 Maven_pom动态去除-snapshot

一、构建

（1）、纯Java代码：编译
（2）、Web工程：编译和部署（把编译的结果“拿”到服务器指定的目录）

Web工程与起编译结果的目录：

构建就是以我们编写的Java代码、框架配置文件、国际化等其他资源文件、JSP页面和图片等静态资源作为“原材料”，去“生产”出一个可以运行的项目的过程

构建过程中的各个环节

1. 清理：将以前编译得到的旧的字节码文件删除，为下一次编译做准备
2. 编译：将Java源程序编译成Class字节码文件
3. 测试：自动测试（让maven自动调用测试程序），自动调用junit程序
4. 报告：测试程序执行的结果
5. 打包：动态Web工程打war包，Java工程打jar包
6. 安装：Maven特定的概念————将打包得到的文件复制到“仓库”中的指定位置
7. 部署：将动态Web工程生成的war包复制到Servlet容器的指定目录下，使其可以运行

自动化的构建

自动化构建好处:

二、Maven得核心概念

1. 约定的目录结构
2. POM
3. 坐标
4. 依赖
5. 仓库
6. 生命周期/插件/目标
7. 继承
8. 聚合

三、第一个Maven工程

1. 约定的目录结构
   

2. 为什么遵守约定得目录结构

• Maven要想自动得进行编译，那么它必须知道Java源文件保存在哪儿
• 如何让框架或工具知道我们自定义的东西
  • 以配置的方式明确告诉框架
    -spring的< param-value >配置属性
  • 遵守框架内部存在的约定

    • log4j.xml

    • log4j.properties

    • 约定>配置>编码

二、常见的Maven命令

• 注意：执行与构建过程相关的Maven命令，必须进入pom.xml所在目录。
  • 与构建过程相关：编译、测试、打包
• 常用命令
  1. mvn clean:清理
  2. mvn compile:编译主程序
  3. mvn test-compile:编译测试程序
  4. mvn test:执行测试
  5. mvn package:打包

三、关于联网的问题

• Maven的核心程序中仅仅定义了抽象的生命周期，但是具体的工作必须由特定的插件来完成。而插件本身并不包含在Maven的核心程序中
• 当我们执行Maven命令需要用到的某些插件时，Maven核心程序会首先到本地仓库去查找
• 本地仓库的默认位置：[ 系统当前用户家目录 ]\.m2\repository
• Maven核心程序如果在本地找不到需要的插件，那么会自动连接外网到外网仓库进行下载
• 可修改默认的本地仓库
  1. Maven安装目录\conf\setting.xml
  2. 在setting.xml文件中找到localRepository标签，并将其从注释中取出
  3. 修改标签体为已经准备好的本地仓库目录

四、POM

1. 含义：Project Object Model 项目对象模型
2. pom.xml对于Maven工程是核心的配置文件，与构建过程相关的一切设置都在这个文件中进行配置

五、坐标

1. 数学中的坐标：
   • 在平面上，使用X、Y两个向量可以唯一的定位平面中的任何一个点
   • 在空间中，是同X、Y、Z三个向量可以唯一的定位空间中的任何一个点
2. Maven的坐标
   • 使用下面三个向量在仓库中国唯一定位一个Maven工程
     1. groupid：公司或组织域名倒序+项目名
     2. artifactid：模块名
     3. version：版本
3. Maven工程的坐标与仓库中路径的对应关系
   

六、仓库

1. 仓库的分类：
   1. 本地长裤：当前电脑上部署的仓库目录，为当前电脑上所有Maven工程服务
   2. 远程仓库
      • 私服：搭建在局域网环境下，为局域网范围内所有的Maven工程服务
      • 中央仓库：架设在Internet上，为全世界所有Maven工程服务
      • 中央仓库镜像：为了分担中央仓库的流量
2. 仓库中保存的内容：Maven工程
   • Maven自身所需要的插件
   • 第三方框架或工具的jar包
   • 我们自己开发的Maven工程

七、依赖[初步]

• Maven解析依赖信息时会到本地仓库中查找被依赖的jar包
  • 对于我们自己开发的工程，使用install命令安装后就可以进入仓库

• 依赖的范围：（使用scope标签包围）

  1. compile(默认)

     • 对主程序是否有效：有效
     • 对测试程序是否有效：有效
     • 是否参与打包：参与

  2. test

     • 对主程序是否有效：无效
     • 对测试程序是否有效：有效
     • 是否参与打包：不参与
     • 是否参与部署：不参与
     • 典型例子：junit

  3. provided

     • 对主程序是否有效：无效
     • 对测试程序是否有效：有效
     • 是否参与打包：不参与
     • 是否参与部署：不参与
     • 典型例子：servlet-api.jar

八、生命周期

• 各个构建环节执行的顺序：不能打乱顺序，必须按照既定的正确顺序来执行
• Maven的核心程序中定义了抽象的生命周期，生命周期中各个阶段的具体任务是由插件完成的
  • Clean Lifecycle
  • Default Lifecycle
  • Site Lifecycle
• Maven核心程序为了更好的实现自动化构建，按照这一特点执行生命周期的各个阶段：不论现在要执行生命周期的哪一个阶段，都是从这个生命周期最初的位置开始执行的
  • compiel
  • test
  • package
• 插件和目标
  1. 生命周期的各个阶段仅仅定义了要执行的任务是什么
  2. 各个阶段和插件的目标是对应的
  3. 相识的目标由特定的插件来完成

插件目标相当于调用插件的命令

九、使用Maven

1. Maven插件
2. Maven插件的设置
   • installations：指定Maven核心程序的位置
   • user setting：指定conf/settings.xml的位置，进而获取本地仓库的位置
3. 基本操作
   • 创建Maven版Java工程
   • 创建Maven版Web工程
   • 执行Maven命令：右键pom.xml–>Run As

注意使用provided为依赖的jar包一定不要使用compile为依赖，否则可能出现严重的问题
例子：jsp-api

IDEA工程通过一些setting文件来识别工程
Maven通过pom.xml来识别工程

十、依赖[高级]

• 依赖的传递性
  

• 好处：可以传递不必再每个工程都重复声明，在“最下面”的工程中依赖一次即可
• 注意：非compile的依赖不能传递。所以在各个工程中，如果有需要就得重复声明依赖

---

• 依赖的排除

  • 需要设置依赖排除的场合
    

  • 依赖排除的设置方式

    • 配置exclusions标签里面的exclusion,写入坐标

  • 依赖的原则

    1. 作用：解决模块工程之间的jar包冲突问题

    2. 情景设定1：验证路径最短优先者的原则
       

    3. 情景设定2：验证路径相同时先声明者优先(指的是在pom.xml中的位置)
       

十一、统一管理依赖版本

• 情景举例
  

这里对Spring各个jar包的依赖都是4.0.0
如果要统一升级到4.1.1，怎么办？手动逐一修改不可靠

• 建议配置方式

  1. 使用properties标签内使用自定义标签统一声明版本号
     

  2. 在需要统一版本的位置，使用${自定义标签}引用声明的版本号
     

• 其实properties标签配合自定义标签声明数据的配置并不是只能用于声明依赖的版本号。凡是需要统一声明后再引用的场合都可以用

十二、继承

• 现状
  Hello依赖junit:4.0
  HelloFriend依赖的junit:4.0
  MakeFriends依赖的junit:4.9

由于test范围的依赖不能传递，所以必然会分散在各个工程中，很容易导致版本不一致

---

• 要求：统一管理各个模块工程中对junit依赖的版本
• 解决思路：将junit依赖统一提取到"父"工程中，在字工程中声明时不指定版本，以父工程中统一设定的为准，同时也便于修改。

---

• 操作步骤

  1. 创建一个Maven工程作为父工程。注意：打包方式是pom

  2. 在子工程中声明对父工程的引用
     

  3. 将子工程的坐标与父工程坐标中重复的内容删除
     

  4. 在父工程中统一junit的依赖
     

  5. 在子工程中删除junit依赖部分的版本号部分

• 配置继承后，执行安装命令时，要先安装父工程

十三、聚合

• 作用：一键安装各个模块的工程

• 配置方式：在一个“总的聚合工程中”配置各个参与聚合的模块
  

• 在聚合工程的pom.xml上右键–>run as–>maven install

十四、自动部署项目

配置build标签
build标签的作用：配置当前工程构建过程中遇到的特殊设置