构建工具Maven
Maven是什么
1、一款服务于Java平台的自动化构建工具
2、构建
● 以源文件、配置文件、页面文件、静态文件等资源为原材料，去生成一个可以运行的工程
● 一个BS项目最终运行的是Web工程的编译结果（class字节码文件组成的）
3、构建的环节
● 清理（clean）：将之前编译过的字节码文件完全删除
● 编译（compile）：将源代码编译成字节码文件
● 测试（test）：自动调用junit的测试程序
● 打包（package）：将工程根据指定的打包方式打成jar或war
● 安装（install）：将打包成功的jar或者war安装到仓库中的指定位置（本地仓库）
Maven的配置
下载maven3.3.9：http://archive.apache.org/dist/maven/maven-3/3.3.9/binaries/apache-maven-3.3.9-bin.zip
1、检查JDK的环境变量配置
2、解压下载后的文件至一个非中文路径的目录下
3、配置Maven的环境变量
● 变量名可以为MAVEN_HOME或者M2_HOME //M2_HOME是一种兼容的配置方式
4、查看配置好的Maven版本：mvn -v
Maven的示例
1、Maven工程的简介
① 约定的目录结构
Hello 工程名
|---src 源码
|---|---main 存放主程序
|---|---|---java 存放Java源文件
|---|---|---resources 存放其他配置文件
|---|---test 存放测试程序
|---|---|---java
|---|---|---resources
|---pom.xml 核心的配置文件
② 约定目录结构的原因
● Maven需要知道源文件所存放的位置才能编译打包
● 遵循约定大于配置，配置大于编码的规范
2、创建一个Maven工程
● 新建一个简单的java类：D:\Hello\src\main\java\com\test\maven\Hello.java，内容如下：
package com.test.maven;
public class Hello {
public String sayHello(String name){
return "Hello "+name+"!";
}
}
● 新建一个简单的java测试类：D:\Hello\src\test\java\com\test\maven\HelloTest.java，内容如下：
package com.test.maven;
import org.junit.Test;
import static junit.framework.Assert.*;
public class HelloTest {
@Test
public void testHello(){
Hello hello = new Hello();
String results = hello.sayHello("litingwei");
assertEquals("Hello litingwei!",results);
}
}
● 新建一个pom.xml文件：D:\Hello\pom.xml，内容如下：
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
3、几个基本的命令
● mvn clean 清理
● mvn compile 编译主程序
● mvn test-compile 编译测试程序
● mvn test 测试
● mvn package 打包
● mvn install 安装至本地仓库中
4、关于联网
● 执行命令之后的功能基本都得由特定的插件来完成，而Maven本身并不包含这些插件
● Maven首先会到本地仓库中查找是否存在该插件（本地仓库默认位置是在当前用户路径下的.m2文件夹下的repository文件夹），可根据需要修改本地仓库的位置（进入Maven的安装目录的conf文件夹中，编辑settings.xml文件，修改配置
● 如果在本地仓库中无法找到需要的插件或其他模块，则需要联网去中央仓库中查找，当无法联网或中央仓库中无法下载到所需的插件或其他模块资源的情况下，则构建失败
5、编译
进入Hello目录下，执行编译命令：mvn compile
POM
POM（Project Object Model）：项目对象模型
pom.xml文件是Maven工程的核心配置文件，可以配置与构建过程相关的一切操作
坐标
Maven中的坐标是通过使用三个向量维度来定位唯一一个Maven工程
● groupid：一般采用公司或组织域名倒序+项目名称的方式
● artifactid：一般采用项目的模块名称
● version：指定版本
仓库
● 仓库类型
本地仓库：当前电脑上的仓库，为当前电脑上所有的Maven工程服务
远程仓库：
私服（相当于中介，主要用于不是所有电脑都能联网的情况）
中央仓库：为全世界的Maven工程服务
中央仓库镜像：分担中央仓库的压力
● 仓库中的内容都以Maven工程的形式保存
Maven自身需要的插件
第三方jar包
自己开发的Maven工程
生命周期
最重要的生命周期：default lifecycle，包括编译、测试、打包、安装和部署等，无论执行的是哪个命令的操作，Maven都会从最初的步骤开始执行到该命令处。
生命周期的各个阶段仅仅定义了要执行的任务是什么，每个阶段都有对应的插件，由特定的插件来完成
使用IDE工具（这里使用eclipse）
1、创建Maven的Java工程
编辑setting.xml文件，找到profiles标签，在其内部加入如下配置指定使用具体版本的JDK
jdk-1.8
true
1.8
1.8
1.8
1.8
右键pom.xml文件，如下选择：
输入命令：
其他命令相似的使用过程
2、创建Maven的Web工程
创建过程是相同的，只是最后打成war包
但是这样创建出来的Web项目没有web.xml这个最关键的部署描述符，所以需要做点修改：
● 右键项目名称 ==》选择属性
● 选择project facets ==》右边找到dynamic web module ==》取消勾选，然后apply ==》再次勾选
● 编辑信息，指定web.xml存放的位置
完成后的Web项目结构图如下：
依赖
1、compile的依赖范围（范围最广，默认的依赖范围）
● 对主程序有效
● 对测试程序有效
● 参与打包
● 参与部署
● 典型：spring-core.jar
2、test的依赖范围
● 对主程序无效
● 对测试程序有效
● 不参与打包
● 不参与部署
● 典型：junit
3、provided的依赖范围
● 对主程序有效
● 对测试程序有效
● 不参与打包
● 不参与部署
● 典型：servlet-api.jar
ps：依赖的范围需要特别注意别依赖错误，否则有可能会报一些很奇怪的找不到原因的错误
4、依赖的传递
当一个项目引入某个依赖后，恰好该依赖也依赖了其他的jar，那么这个其他的jar也会跟着一起被依赖到现在的工程中，这就是依赖的传递
ps：非compile域范围内的jar依赖无法被传递
5、依赖的排除
依赖的排除正好是与依赖的传递相反的概念，当由于某个依赖被传递后导致与现有的jar发生冲突或者多个依赖之间由于版本不一导致冲突发生时，需要将某个依赖的传递排除掉
使用
标签进行排除
ps：如果A工程排除的依赖处于中间层的话，当其他工程依赖A工程时也不会有被排除的依赖传递下去
6、依赖的原则
为了解决jar包之间的冲突问题，Maven的依赖有如下原则：
● B工程依赖了A工程，A工程中有一个依赖的版本为1.1被传递下来，B工程中恰好有该依赖且版本为1.2，此时C工程依赖了B工程，那么C工程中对应的该依赖的版本为1.2 //原则一：路径最短者优先
● A工程（z依赖的版本1.1），B工程（z依赖的版本1.2），C工程同时依赖A工程和B工程，此时，C工程如果在pom.xml文件中先声明依赖A工程，则z依赖的版本为1.1；而如果C工程在pom.xml文件中先声明的是B工程，则对应的z依赖的版本为1.2 //原则二：路径相同时，先声明者优先
7、依赖的统一管理
场景：需要对某一些依赖的版本做统一版本的升级
● 在
● 采用父工程的形式也能达到同样的效果
Maven的继承
场景：z依赖可以为junit（原因在于junit的作用域范围就是test，不能进行依赖传递，所以junit就是会零散的分布在不同的工程模块中，导致可能出现版本不相同的情况）
A工程的z依赖的版本为4.0
B工程的z依赖的版本为4.0
C工程的z依赖的版本为4.9
解决方法：创建一个父工程（打包方式为pom），指定具体的版本，在子工程中引用z依赖时不指定版本，交由父工程统一做版本管理 //子工程和父工程的关系就是继承的关系
父工程：
配置了依赖管理后并不会真的另子工程依赖父工程所配置的依赖，而是当子工程需要某个依赖时，直接在pom.xml文件中配置groupId和artifactId标签即可
子工程：
Maven的聚合
方便构建，只需构建一个父工程即可完全对所有子工程的构建
在父工程的pom.xml文件配置如下：
ps：Maven的中央仓库：https://mvnrepository.com/
完！