Maven
*常用maven命令：
1.mvn clean:清理
2.mvn compile:便宜主程序
3.mvn test-compile:编译测试程序
4.mvn test:执行测试
5.mvn package:打包
6.mvn insetall 把自定义的maven项目安装到本地仓库
7.mvn site:生成站点
*构建过程中的各个环节：
1.清理：将以前编译得到的旧的class字节码文件删除，为下一次编译做准备。
2.编译：将Java源程序编译成class字节码文件。
3.测试：自动测试，自动调用junit程序。
4.报告：测试程序执行的结果。
5.打包：动态Web工程打war包，Java工程打jar包。
6.安装：Maven特定的概念——将打包得到的文件复制到"仓库"中的指定位置。
7.部署：将动态Web工程生成的war包复制到Service容器的指定目录下，使其可以运行。
*Maven的核心概念
1.约定的目录结构
2.POM
3.坐标
4.依赖
5.仓库
6.生命周期/插件/目标
7.继承
8.聚合s
*POM
1.含义：Project Object Model 项目对象模型
DOM Document Object Model 文档对象模型
2.pom.xml对于Maven工程是核心配置文件，与构建过程相关的一切设置都在这个文件中进行配置。
重要程度相当于web.xml对于Web工程
*坐标
1.数学中的坐标:
①.在平面上，使用X,Y两个向量可以唯一的定位平面中的任何一个点。
②.在空间中，使用X、Y、Z三个向量，可以唯一的定位空间中的任何一个点。
2.Maven的坐标
使用下面三个向量在仓库中唯一定位一个Maven工程
①groupid:公司或组织域名倒叙+项目名
<groppid>com.bawei.maven</groupid>
②artifactid:模块名
<artifactid>Hello</artifactid>
③version:版本
<version>1.0.0</version>
3.Maven工程坐标与仓库中路径的对应关系
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>4.0.0.RELEASE</version>
org/springframework/spring-core/4.0.0.RELEASE/spring-core-4.0.0.RELEASE.jar
*仓库
1.仓库的分类
①本地仓库：当前电脑哦啊上步数的仓库目录，为当前电脑上所有Maven工程服务
②远程仓库：
(1)私服；搭建在局域网环境中，为局域网范围内的所有Maven工程服务
(2)中央仓库：架设在Internet上，为全世界所有的Maven工程服务
(3)中央仓库的镜像：为了分担中央仓库的流量，提升用户访问速度
2.仓库中保存的内容：Maven工程
①Maven自身所需要的插件
②第三方框架或工具的jar包
③我们自己开发的Maven工程
*依赖[初步]
1.Maven解析依赖信息时会到本地仓库中寻找依赖jar包。
对于我们自己开发的Maven工程，使用install命令安装后，就可以进入仓库
2.依赖的范围
①compile范围依赖
·对主程序是否有效：有效
·对测试程序是否有效：有效
·是否参与打包：参与
·典型例子：spring-core
②test范围依赖
·对主程序是否有效：无效
·对测试程序是否有效：有效
·是否参与打包：不参与
·典型例子：junit
③provided范围依赖
·对主程序是否有效：有效
·对测试程序是否有效：有效
·是否参与打包：不参与
·是否参与部署：不参与
·典型例子：servlet-api.jar
*生命周期
1.各个构建环节执行的顺序：不能打乱顺序，必须按照既定的正确顺序来执行。
2.Maven的核心程序中定义了抽象的生命周期，生命周期中各个阶段的具体任务是由插件完成的。
3.Maven核心程序为了更好的实现自动化构建，按照这样的特点执行生命周期的各个阶段：不论现在要执行生命周期的哪一个阶段，都是从这个生命周期最初的位置开始执行
4.插件和目标
①生命周期的各个阶段仅仅定义了要执行的任务是什么。
②各个阶段和插件的目标是对应的。
③相似的目标由特定的插件来完成。
④可以将目标看作"调用插件功能的命令"。
*在Eclipse中使用Maven
1.Maven插件:Eclipse内置
2.Maven插件的设置：
①installations:指定Maven核心程序的位置，不建议使用插件自带的Maven程序，而应该使用我们自己解压的那个。
②user settings:指定conf/settings.xml的位置，进而获取本地仓库的位置。
③基本操作
(1)创建Maven版的Java工程
(2)创建Maven版的Web工程
(3)执行Maven命令
*依赖[高级]
1.依赖的传递性
①好处：可以传递的依赖不必在每个模块工程中都重复声明，在"最下面"的工程中依赖一次就可以了。
②注意：非compile范围的依赖不能传递。所以在各个工程模块中，如果有需要就要重复声明依赖。
2.依赖的排除
①需要设置以来排除的场合(知道要排除哪个jar包，单独工程生效)
②依赖排除的设置方式
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
3.依赖的原则
①作用：解决模块工程之间的jar包冲突问题
②情景设定1：验证路径最短者优先原则
③情景设定2：验证路径相同时，先声明者优先(指的是dependency标签的声明顺序)
4.统一管理依赖的版本
情景模拟：Spring的各个jar包的依赖版本都是4.0.0
要统一升级成4.1.1;手动逐一修改不可靠
建议配置方式
(1)使用properties标签内使用自定义标签统一声明版本号
<properties>
<aaa>4.0.0.RELEASE</aaa>
</properties>
(2)在需要统一版本的位置，使用$(自定义标签名)引用声明的版本号
<version>${aaa}</version>
(3)其实properties标签配合自定义标签声明数据的配置并不是只能声明依赖的版本号。凡是需要统一声明后才可以引用的都可以采用
*继承
1.现状
Hello依赖的junit:4.0
HelloFriend依赖的junit:4.0
MakeFriends依赖的junit:4.9
由于test范围的依赖不能传递，所以必然会分散在各个模块工程中，很容易造成版本不一致
2.需求：统一管理各个模块工程中对junit依赖的版本
3.解决思路：将junit依赖版本统一提取到"父"工程中，在子工程中声明依赖时不指定版本，以父工程中统一设定的为准。同时也便于修改。
4.操作步骤：
①创建一个Maven工程作为父工程，注意：打包的方式pom
②在子工程中声明对父工程的引用
③将子工程的坐标中与父工程坐标中重复的内容删除
④在父工程中统一管理junit的依赖
⑤在子工程中删除junit依赖的版本号部分