Maven工具-简介
①maven是一款服务于java平台的自动化构建工具
make→Ant→maven→Gradle
②构建
【1】概念：以“java源文件”、“框架配置文件”、‘JSP’、“HTMl”、“图片”等资源为“原材料”，去生产一个可以运行的项目的过程
编译
部署
搭建
【2】编译：java源文件【User.java】→编译→Class字节码文件【User.class】→交给JVM去执行
【3】部署：一个BS项目最终运行的并不是动态web项目本生，而是这个动态web工程‘编译的结果’
生的鸡→处理→熟的鸡
动态web工程→编译 、 部署→编译结果
Tips：tc_server
eclipse 插件，能够知道项目部署的位置
③构建过程中的各个环节
【1】清理：将以前编译得到的旧的class文件删除，为下一次编译做准备
【2】编译：将java源程序编译成class字节码文件
【3】测试：自动测试，自动调用junit程序
【4】报告：测试程序执行的结果
【5】打包：动态web工程打war包，java工程打jar包
【6】安装：maven特定的概念---将打包得到的文件复制到‘仓库’中的指定位置
【7】部署：将动态的web工程生成的war包复制到servlet容器的指定目录下，使其可以运行
④自动化构建
编译→打包→部署→测试
没有maven的时候开发出现的问题
①一个项目就是一个工程
如果项目庞大，就不适合继续使用package来划分模块，最好是每一块模块对应一个工程，利于分工协 作，借助于Maven就可以将一个项目拆分成多个工程
②项目中需要的jar包必须手动“复制”、“粘贴”到WEB-INF/lib目录下
带来的问题是：同样的jar包文件重复出现不同的项目工程中，一方面浪费存储空间，另外也让工程比较臃肿
借助Maven，可以将jar包仅仅保存在“仓库”中，有需要使用的工程“引用”这个文件接口，并不需要真的把jar包复制过来
③jar包需要别人替我们准备好，或者到官网下载
不同技术的官网提供jar包下载的形式是五花八门的
有些技术的官网就是通过Maven或SVN等专门的工具来提供下载的
如果是以不规范的方式下载的jar包，那么其中的内容很可能也是不规范的
借助于maven可以规范的下载jar包，因为所有的知名框架或第三方工具的jar包以及按照统一的规范存放在maven的中央仓库中
规范的方式下载jar包，内容也是可靠的
Tips：“统一的规范”不仅是对IT开发领域非常重要，对于整个人类社会都是非常重要的
④一个jar包依赖的其他jar包需要自己手动加入到项目中
FileUpload组件→IO组件 commons-fileupload-1.3.jar依赖于commons-io-2.0.1.jar
如果所有jar包之间的依赖关系需要程序员自己非常清楚的了解，那么就会极大的增加学习成本
maven会自动将被依赖的jar包导入进来。
浏览器| --->|表示层/表述层/表现层| ---> |业务逻辑层| ---> |持久化层| --->|DB
| | |
V V V
视图层 控制层 Spring IOC AOP JDBC/DBUtils/Spring JDBCTemplate/
| | Hibernate/MyBatis
V V
H5/CSS/JSP Servlet/Action/Handler
①检查JAVA_HOME环境变量
②解压maven核心程序的压缩包，放在一个非中文无空格路径下
③配置maven相关的环境变量
【1】 MAVEN_HOME 或 M2_HOME F:\ruanjiangc\apache-maven-3.6.2
【2】 path F:\ruanjiangc\apache-maven-3.6.2\bin
④验证：运行mvn -v命令查看 maven版本
①约定的目录结构
②POM
③坐标
④依赖
⑤仓库
⑥生命周期/插件/目标
⑦继承
⑧聚合
①创建约定的目录结构
【1】根目录：工程名
【2】src目录：源码
【3】pom.xml文件：maven工程的核心配置文件
【4】main目录：存放主程序
【5】test目录：存放测试程序
【6】java目录：存放java源文件
【7】resource目录：存放框架配置文件或其他工具的配置文件
②为什么要遵守约定的目录结构呢
maven要负责我们这个项目的自动化构建，以编译为例，maven要自动进行编译，那么它必须要知道java源文件保存在哪里
如果我们自己自定义的东西想要让框架或工具知道，有两种办法
以配置的方式明确告诉框架 <param-value>classpath:spring-context.xml</param-vlue>
遵守框架内部已经存在的约定 log4.properties 或 log4.xml
约定>配置>编码
①注意：执行与构建过程相关的maven命令，必须进入pom.xml所在的目录
与构建过程相关：编译，测试，打包。。。。。
②常用命令
【1】mvn clean:清理
【2】mvn compile：编译主程序
【3】mvn test-compile：编译测试程序
【4】mvn test：执行测试
【5】mvn package：打包
【6】mvn install：安装
【7】mvn site：生成站点
①maven的核心程序中仅仅定义了抽象的生命周期，但是具体的工作必须由特定的插件来完成。而插件本身 并不包含在maven的核心文件中
②当我们执行的maven命令需要用到某些插件时，maven核心程序会首先到本地仓库中查找
③本地仓库的默认位置：用户.m2\repository C:\Users\Administrator.m2\repository
④maven核心程序如果在本地仓库中找不到需要的插件，那么它会自动连接外网，到中央仓库下载。
⑤如果此时无法连接外网，则构建失败
⑥修改默认本地仓库的位置可以让maven核心程序到我们事先准备好的目录下查找插件
【1】找到maven解压目录\conf\settings.xml
【2】在settings.xml文件中找到ocalRepository标签
【3】将/path/to/local/repo从注释
【4】将标签体内容修改为已经准备好的maven仓库目录
F:\RepMaven
①含义：Project Object Model项目对象模型
DOM Document Object Model 文档对象模型
②pom.xml对于maven工程是核心配置文件，与构建过程相关的一切设置都在这个文件中进行配置
重要程度相当于动态web工程中的web.xml
①在数学坐标中
【1】在平面上：使用x,y定位
【2】在三维中：使用x,y,z定位
②maven的坐标
使用下面三个向量在仓库中唯一定位一个maven工程
【1】groupid：公司或者组织域名倒叙+项目名
com.zyf.maven
【2】artifactid:模块名
Hello
【3】version：版本
1.0.0
③maven工程的坐标与仓库中路径对应的关系
com.google.code.findbugs
jsr305
2.0.1
com/google/code/findbugs/jsr305/2.0.1/jsr305-2.0.1.jar
① 仓库的分类
【1】本地仓库:当前电脑上部署的仓库目录，为当前电脑上所有maven工程服务
【2】远程仓库
（1）私服：搭建在局域网环境中，为局域网范围内的所有maven工程服务
（2）中央仓库：架设在internet上，为全世界所有的maven工程服务
（3）中央仓库镜像：为了分担中央仓库的流量，提升用户访问速度
② 仓库中保存的内容：maven工程
【1】maven自身所需要的插件
【2】第三方框架或工具的jar包
【3】我们自己开发的maven工程
①maven解析依赖信息时会到本地仓库中查找被依赖的jar包
对于我们自己开发的maven工程，使用mvn install命令安装后就可以进入仓库
②依赖的范围
【1】compile范围依赖
对主程序是否有效：有效
对测试程序是否有效：有效
是否参与打包：参与
【2】test范围依赖
对主程序是否有效：无效
对测试程序是否有效：有效
是否参与打包：不参与
【3】provided范围依赖
对主程序是否有效：有效
对测试程序是否有效：有效
是否参与打包：不参与
是否参与部署：不参与
典型的例子：servlet-api.jar
①各个构建环节执行的顺序：不能打乱顺序，必须按照既定的正确顺序来执行
②maven的核心程序中定义了抽象的生命周期，生命周期中各个阶段的具体任务由插件来完成
③ maven核心程序为了更好的实现自动化构建，按照这一的特点执行生命周期中的各个阶段：不论现在要执行生命周期中的哪一个阶段，都是从这个生命周期最初的位置开始执行。
④插件和目标
【1】生命周期的各个阶段仅仅定义了要执行的任务是什么
【2】各个阶段和插件的目标是对应的
【3】相似的目标由特定的插件来完成
生命周期阶段 插件目标 插件
compile compile maven-compile-plugin
test-compile testCompile maven-compile-plugin
【4】可以将目标看作‘调用插件功能的命令’
①依赖的传递性
【1】好处：可以传递的依赖不必在每个模块工程中的重复声明，在‘最下面’的工程中依一次即可。
【2】注意：非compile范围的依赖不可传递。所以在各个工程模块中，如果有需要就得重复声明依赖。
②依赖的排除
【1】需要设置依赖排除的场合（原因）
不稳定的jar包，不希望加入到当前的工程中
【2】依赖排除的设置
<exclusions>
<excludion>
<groupId> </groupId>
<artifactId> </artifactId>
</exclusion>
</exclusions>
③依赖的原则
【1】作用：解决了模块工程之间的jar包冲突问题
【2】情景设定1：验证路径最短优先原则
MakeFriends → HelloFriend → Hello
| | |
v v V
log4j.1.2.14 log4j.1.2.14 log4j.1.2.17
【3】情景设定3：验证路径相同时先声明者优先
MakeFriends → HelloFriend → Hello
|
|————————————> OurFriends————> log4j.1.2.17
先声明指的是dependency标签的声明顺序
④统一管理依赖的版本
【1】情景举例
这里对Spring各个jar包的依赖版本都是4.0.0
如果需要统一升级为4.1.1，怎么办? 手动逐一修改不可靠
【2】建议配置方式
i.使用properties标签内使用自定义标签统一声明版本号
<properties>
<atguigu.spring.version>4.1.1.RELESASE</atguigu.spring.version>
</properties>
ii.在需要统一版本的位置，使用${自定义标签名} 引用声明的版本号
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${atguigu.spring.version}</version>
【3】其实properties标签配合自定义标签声明数据的配置并不是只能用于声明依赖的版本号
统一声明后再引用的场合都可以使用
<properties>
<atguigu.spring.version>4.1.1.RELESASE</atguigu.spring.version>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<aa.bb.cc> </aa.bb.cc>
</properties>