maven
为什么用maven？
啊哈：不使用maven的不适应之处：
1.一个项目就是一个工程
实际中，如果一个项目比较庞大，就不太适合使用package来划分模块。最好是每一个模块对应一个工程，利于分工协作。
借助maven，可以将一个项目拆分成多个工程。
2.项目中的jar包必须手动 “复制”，“粘贴” 到 lib 目录下。
带来的问题是：同样的 jar包重复出现再不同的项目工程中，一方面浪费存储空间，另外也让工程比较臃肿。
借助maven，可以将jar包仅仅保存再仓库中，又需要使用的工程"引用" 这个文件接口，并不需要真的把jar包复制过来。
3.jar包需要别人为我们准备好或者是去官网进行下载
不同技术的官网提供下载jar包的形式不太一致
有些技术就是通过Maven和SVN等专门的工具来提供下载。
非正式的方式下载的jar包其内容也可能是不正确的。
借助maven可以以一种规范的方式下载jar包，因为知名的框架或第三方工具的jar包以及按照统一的规范存放再了Maven的中央仓库中。
以规范的方式下载jar包，内容也是可靠的。
TIP：统一的规范对整个社会都是比较重要的，比较有意义的。
4.一个jar包所依赖的其他jar包需要手动进行导入。
FileUpload组件 --> IO组件。commons-files.jar包依赖于commons-io.jar包。
如果所有jar包之间的依赖都需要程序员自己非常清楚的了解，那么学习的成本就极大。
Maven会自动的将被依赖的包导入出来。
Maven是什么？
Maven是一款服务于java平台的自动化构建工具。
历程：
Make-->Ant-->Maven-->Gradle
构建：
1 ). 以 “java源文件”、"框架配置文件"、“jsp”、“html”、“图片”等资源为“原材料”，去生产一个可以运行的项目的过程。
过程：
编译。
Java源文件 --->编译 --->Class字节码文件 -->交给JVM执行。
部署。
一个BS项目最终运行的并不是动态WEB工程本身，而是这个动态WEB工程 "编译的结果"。
Tips：运行时环境
其实是一组jar包的引用，并没有把jar包的本身复制到工程中，所以并不是目录。
browser deployment location:右键点击有一个插件。
开发过程中，所有的路径或配置文件中配置的类路径等都是以编译结果的目录结构为标准。
搭建。
构建过程中的各个环节：
1）清理：将以前编译得到的旧class文件删除，为下一次编译作准备
2）编译：将java源程序编译成class字节码文件
3）测试：自动测试，自动调用junit程序
4）报告：测试程序执行的结果
5）打包：动态web工程打war包，java工程打jar包
6）安装：Maven特定的概念，将打包得到的文件复制到仓库中的指定位置
7）部署：将动态web工程生成的war包复制到servlet容器的指定目录下，使其可以运行
自动化构建：
安装maven核心程序：
1.检查JAVA_HOME环境变量 cmd: echo %JAVA_HOME% E:\StudySoft\java\jdk
2.解压 
文件放在没有中文以及空格的目录下
3.配置Maven的相关环境变量
【1】MAVEN_HOME或M2_HOME
【2】path
4.运行mvn -v查看Maven版本 可以看到版本号 即为配置成功
5.Maven的核心概念
(1).约定的目录结构
(2).POM
(3).坐标
(4).依赖
(5).仓库
(6).生命周期/插件/目标
(7).继承
(8).聚合
6.第一个Maven工程
1.创建一个约定的目录结构
1*：根目录：工程名
2*：src目录：源码
3*：pom.xml文件：Maven工程的核心配置文件
4*：main目录：存放主程序
5*：test目录：存放测试程序
6*：java目录：存放java源文件
7*：resources目录：存放框架或其他工具的配置文件
2.为什么要遵守约定的目录结构：
*：Maven要负责我们这个项目的自动化构建，以编译过程为例，Maven要想自动进行编译，那么必须知道java源文件保存在哪里
*：如果我们自定义的东西想要让框架或工具知道，有两种办法：
1.以配置的方式明确告诉框架
也就是spring在web.xml的配置
2.遵守框架内部已经存在的约定 eg:
log4j.properties 或 log4j.xml
*：约定 》 配置 》 编码
7.常用Maven命令
1).注意：执行与构建过程相关的Maven命令，必须进入pow.xml所在的目录
与构建过程相关：编译、测试、命令 2).常用命令：
【1】mvn clean : 清理
【2】mvn compile : 编译主程序
【3】mvn test-compile : 编译测试程序
【4】mvn test ： 执行测试 【5】mvn package : 打包
【6】mvn install：安装
【7】mvn site：生成站点
8.关于联网的问题：
(1).Maven的核心程序中仅仅定义了抽象的生命周期，但是具体的工作必须由特定的插件来完成，而插件本身并不包含在Maven的核心程序中。
(2).当我们执行的Maven命令需要用到某些插件时，Maven核心程序会首先到本地仓库中查找
(3).本地仓库的默认位置：【系统中当前用户的家目录】\.m2.\repository
(4).Maven核心程序如果在本地仓库中找不到需要的插件，那么他会自动链接外网，到中央仓库下载
(5).如果此时无法链接外网，则构建失败。
(6).修改默认本地仓库的位置可以让Maven核心程序到我们事先准备好的目录下查找插件
【1】找到Maven的解压目录\conf\settings.xml
【2】在setting.xml文件中找到 localRepository 标签
【3】将 <localRepository>/path/to/local/repo</localRepository> 从注释中取出
【4】标签体内容修改为已经准备好的Maven仓库目录
9.POM
1.含义：Project Object Model 项目对象模型
类似：DOM：Document Object Modal文档对象模型
2.pom.xml 对于Maven工程是核心的配置文件，与构建过程相关的一切设置都在该文件中进行配置
重要程度相当于：web.xml对于动态工程
10.坐标
1.数学中的坐标：
1》在平面上使用x，y 两个向量可以唯一的定位平面中的任何一个点。
2》在空间中使用 x,y,z 三个向量可以唯一的定位空间中的任何一个点
2.Maven中的坐标：
使用下面三个向量在仓库中唯一定位一个Maven工程
gav
【1】groupId：公司或组织域名倒序加上项目名
<groupid>com.test.maven</groupid>
【2】artifactid：模块名
<artifactid>Hello</artifactid>
【3】version：版本
<version>1.0.0</version>
3.Maven工程的坐标与仓库中路径的对应关系
11.仓库
1.仓库的分类：
【1】本地仓库：当前电脑上部署的仓库目录，为当前电脑上所有Maven工程服务
【2】远程仓库：
(1).局域网(私服)：搭建在局域网环境中，为局域网范围内的所有Maven工程服务
(2).中央仓库：架设在Internet上，为全世界所有Maven工程服务
(3).中央仓库镜像：为了分担中央仓库的流量，提升用户访问速度
2.仓库中保存的内容：Maven工程
【1】Maven自身所需要的插件
【2】第三方框架或工具的jar包
【3 】我们自己开发的Maven工程
12.依赖[初步]
1.Maven解析依赖信息时会到本地仓库中查找被依赖的包
对于我们自己开发的Maven工程，使用install命令安装后即可进入仓库
2.依赖的范围
【1】compile范围依赖：
*：对主程序是否有效：有效
*：对测试程序是否有效：有效
*：是否参与打包： 参与
【2】test范围依赖：
*：对主程序是否有效：无效
*：对测试程序是否有效：有效
*：是否参与打包： 不参与
* : 典型例子：jUnit
【3】provided范围依赖：
*：对主程序是否有效：有效
*：对测试程序是否有效：有效
*：是否参与打包： 不参与
*：不参与部署
*：典型例子：servlet-api.jar
13.生命周期
【1】各个构建环节执行的顺序：不能打乱顺序，必须按照既定的正确顺序来执行。
【2】Maven的核心程序定义了抽象的生命周期，生命周期中各个阶段的具体任务是由插件来完成的。
【3】Maven核心程序为了更好的实现自动化构建，按照这一特点执行生命周期中的各个阶段：不论现在要执行生命周期中的哪一个阶段，
都是从这个生命周期最初的位置开始执行。
【4】插件和目标：
*：生命周期的各个阶段仅仅定义了要执行的任务是什么
*：各个阶段和插件的目标是对立的
*：相似的目标由特定的插件来完成
*：可以将目标看作“调用插件的命令”
14.在Eclipse中使用Maven
1.Maven插件：Eclipse内置
2.Maven插件的设置：
【1】installions：指定Maven核心程序的位置。不建议使用插件自带的Maven程序。而应该使用我们解压的程序。
【2】user settings：指定conf/settings.xml 的位置，进而获取本地仓库的位置。
3.基本操作：
【1】创建Maven版的java工程
【2】创建Maven版的Web工程
【3】执行Maven命令
15.依赖(高级)
1.依赖的传递性
【1】好处：可以传递的依赖不必在每个模块工程中都重复声明，在 “最下面”的工程中依赖一次即可。
【2】注意：非compile范围的依赖不能传递。所以在各个工程模块中，如果又需要就得重复声明依赖
2.依赖的排除
【1】需要设置依赖排除的场合
【2】依赖的排除设置操作
【3】依赖的原则
【1】作用：解决模块工程之间的jar包冲突的问题
【2】情景设定1：验证路径最短者优先原则
【3】情景设定2：验证路径相同时先声明着优先
先声明：dependence标签的优先级
【4】统一管理依赖的版本
【1】情景举例：
这里对Spring各个jar包的依赖版本都是4.0.0
如果需要统一升级为4.1.1，怎么办？手动逐一修改不可靠
【2】建议配置方式
*：使用properties标签内使用自定义标签统一声明版本号
*：在需要统一版本的位置，使用${自定义标签名}引用声明的版本号
*：其实properties标签配合自定义标签声明数据的配置并不是只能用于声明版本号。凡是需要统一声明后再引用的场合都可以使用
16.继承(配置后执行安装命令时需要先安装父工程)
【1】现状
Hello依赖的junit：4.0
HelloFriend依赖的junit：4.0
MakeFriends依赖的junit：4.9
test范围的依赖由于不能传递，所以必然会分散在各个模块工程中，很容易造成版本不一致
【2】需求：统一管理各个模块工程中对junit依赖的版本号
【3】解决思路：将junit依赖版本统一提取到”父“工程中，在子工程中声明依赖时不指定版本，以父工程中统一设定为准。同时也便于修改
【操作步骤】
【1】创建一个Maven工程作为父工程。注意：打包的方式pom
【2】在子工程中声明对父工程的引用
【3】将子工程的坐标中与父工程中重复的内容删除
【4】在父工程中统一管理junit的依赖
【5】在子工程中删除junit依赖的版本号部分
17.聚合
1.作用：一键安装各个模块工程
2.配置方式：在一个总的聚合工程中配置各个参与聚合的模块
3.使用方式：在聚合工程的pom.xml上点右键-》run as -》maven install
