自动化构建工具：Maven_automation maven

引入maven的原因

之前的技术存在的问题：

1. 一个项目就是一个工程（创建web工程为例，所有的功能都在这一个工程里，类似于以package来划分模块）。而我们希望每一个模块是有自己的工程，则每个项目划分为多个模块就是多个工程（这样的话每个项目组可以在各自的工程里进行开发）==> 可借助Maven将一个项目划分为多个工程
2. 项目中需要的jar包必须手动“复制”、“粘贴”到WEB-INF/lib目录下 ==> 借助Maven，可以将jar包仅仅保存在“仓库”中，有需要使用的工程直接“引用”这个文件接口，不需要真的把jar包复制过来
3. 一个jar包依赖的其他jar包需要自己手动加人到项目中
   所有知名框架或者第三方工具的jar包按照统一规范放在了Maven的中央仓库中，在需要使用一个jar包时，Maven会自动将其所依赖的jar包导入进来

一 什么是Maven

1.maven概念：是一款服务于Java平台的自动化构建工具（何为“构建”，即以“Java源文件”，“框架配置文件”，“JSP”，“图片”等资源为“原材料，去“生产”一个可以运行的项目的过程，历经编译、部署、搭建

• 编译：Java源文件-》编译-》class字节码文件交给JVM去执行
• 部署：一个BS项目最终运行的并不是动态Web工程本身，而是动态Web工程“编译的结果”=》在开发过程中，所有的路径或配置文件中配置的类路径都是以编译结果的目录结构为标准的。通过浏览器访问Java程序时，就必须将Java程序的Web工程编译的结果“拿到”服务器的指定目录下，再启动服务器即可，这个“拿”的过程即为部署。

#####Tips:写类路径时要以编译结果为依据，不能以工程本身的目录路径结构为标准（webContent里的内容全跑到项目下面了，classes不变）
2.构建过程中的各个环节

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

二 安装Maven核心程序

1.检查JAVA_HOME环境变量
2.解压Maven核心程序的压缩包，放在一个非中文无空格的路径下
3.配置Maven相关环境变量（MAVEN_HOME、path）
4.验证：运行mvn -v命令查看Maven版本

三 Maven的核心概念

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

四 创建Maven工程

1.创建约定的目录结构

• 根目录：工程名

  • src目录：源码
    • main目录：存放主程序
    • test目录：存放测试程序
  • pom.xml文件：Maven工程的核心配置文件
    （通过到此上一级，执行mvn compile,可得编译后的文件target在同一层级，通过命令mvn clean可删除编译后的结果）
    

• java目录：存放Java源文件

• resource目录：存放框架或者其他工具的配置文件

五 Maven联网问题

Maven核心程序如果在本地仓库中找不到需要的插件，会自动连接外网，到中央仓库下载

六 POM

1.含义：project object model项目对象模型
类似DOM（Document Object Model）文档对象模型
2.pom.xml对于Maven工程是核心配置文件，与构建过程相关的一切设置都在这个文件中进行配置（其重要程度相当于web.xml对于动态web工程）

七 坐标

1.作用：使用三个向量在仓库中唯一定位一个Maven工程，Maven需要通过坐标才能找到依赖
2.三个向量gav：
【1】groupid:公司名或者组织域名倒序+项目名

<groupid>组织域名.项目名</groupid>
1

【2】artifactid:模块名

<artifactid>模块名</artifactid>
1

【3】version：Maven的版本

<version>1.0.0</version>
1

3. Maven工程的坐标与仓库中路径的对应关系

	<groupid>org.springframework</groupid>
	<artifactid>spring-core</artifactid>
	<version>1.0.0.RELEASE</version>
	=>(本地)仓库中路径：org/springframework/spring-core/1.0.0.RELEASE/spring-core-1.0.0.RELEASE.jar
1
2
3
4

八 仓库

• 仓库的分类
  • 本地仓库：当前电脑上部署的仓库目录，为当前电脑上所有Maven工程服务
  • 远程仓库：
    • 私服：搭建在局域网环境中，为局域网范围内所以Maven工程服务
    • 中央仓库：架设在Internet上，为全世界所以Maven工程服务
    • 中央仓库镜像：为了分担中央仓库的流量，提升用户访问速度
• 仓库中保存的内容（是Maven工程）
  • Maven自身所需要的插件
  • 第三方框架或工具的jar包
  • 自己开发的Maven工程

第一方是jdk，第二方是我们自己
1

九 依赖

1. Maven解析依赖信息是会用到本地仓库中查找被依赖的jar包，通俗的说，如果一个Maven构建所产生的构件（如Jar文件）被其他项目引用，那么该构件就是其他项目的依赖

• 导入依赖的方法

    <dependencies>//dependencies元素包含一个或者多个dependency子元素
        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>servlet-api</artifactId>
            <version>2.5</version>
            <scope>provided</scope>//依赖范围，默认是compile
        </dependency>
    </dependencies>
1
2
3
4
5
6
7
8

2. 依赖的作用
   解决模块工程之间的jar包冲突问题
3. 依赖的范围

（1）complie范围的依赖（全程有效）

• 对主程序是有有效：有效
• 对测试程序是否有效:有效
• 是否参与打包：参与
• 是否参与部署：参与
• 典型例子：spring-core（Spring core核心容器是用来负责发现、创建并处理bean之间的关系的一个工具包；提供spring的基本功能）
  

（2） test范围依赖

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

（3）provided范围依赖（即该依赖只在编译测试时有效）

• 对主程序是有有效：有效
• 对测试程序是否有效:有效
• 是否参与打包：不参与
• 是否参与部署：不参与（因为开发时，本工程里没有Tomcat的运行时环境，用到servlet时需要这种jar包）
• 典型例子：servlet-api.jar

4. 依赖的特性
   （1) 依赖的传递性
   依赖的传递性

• 好处：可以传递的依赖不必在每个模块工程中都重复声明
• 注意：非compile范围的依赖不能传递，so在各个工程模块中，若有需要就得重复申明
  （2）依赖的排除
• 需要设置依赖排除的场合：不稳定jar包，不希望加入当前工程
• 排除依赖的方式：

<exclusions>
	<exclusion>
		<groupid>组织域名.项目名</groupid>
		<artifactid>模块名</artifactid>
	<exclusion>
<exclusions>
	
1
2
3
4
5
6
7

5. 依赖的原则

• 验证路径最短者优先原则
  
• 验证路径相同时先声明者优先（即dependency标签的声明顺序）
  

6. 统一管理依赖的版本
   （1）使用场景：对Spring各个jar包的依赖版本都是4.0.0.当需要统一升级为4.1.1时
   （2）解决方法（即配置方式）

• 使用properties标签使用自定义标签统一版本号

<properties>
	<自定义标签名>4.0.0.RELEASE</自定义标签名>
</properties>
1
2
3

(3)在需要统一版本的位置，使用${自定义标签名}引用声明的版本号
1

<version>${自定义标签名}</version>
1

十 Maven生命周期

Maven生命周期详解

十一 插件

1. 各个构建环节执行的顺序：不能打乱顺序，必须按照既定的正确顺序来执行
2. Maven的核心程序中定义了抽象的生命周期，生命周期中的各个阶段的具体任务是由插件来完成的
3. Maven插件plugin和依赖的区别

十二 继承

1. 需要继承的原因:以test范围的依赖为例，由于test范围的依赖不能传递，则必然会分散在各个模块工程中，很容易造成版本不一致，所以需要统一管理各个模块中对于junit依赖的版本
2. 解决思路：将junit依赖统一提取到“父”工程中，在子工程中声明junit依赖时不指定版本，以“父”工程设定的为准，同时也便于修改
3. 步骤：

• 创建一个Maven工程作为父工程。注意：打包的方式为pom，而不是war包
  

• 在子工程中声明对父工程的引用
  <parent>...</parent>
  

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

• 在父工程中统一管理junit的依赖
  <dependencyManagement>...</dependencyManagement>

• 在子工程中删除junit的依赖的版本号

4. 注意：配置继承后，执行安装命令时要先安装父工程

十三 聚合

1. 作用：一键安装各个模块工程
2. 配置方式：在一个“总的聚合工程”中配置各个参与聚合的模块
   <modules></modules>
   
3. 使用方式：在聚合工程的pom.xml上右键->run as->maven install

十四 Maven自动部署

1.部署的定义：一套代码获取到编译再到打包发布的完整流程（ 即maven-scm-plugin或者maven-release-plugin插件的使用）

• **java项目和web项目对比