Maven深入了解
- 前言
- 一、Maven的核心概念
- 1.1 Maven-Jar包+模块化管理
- 1.2 POM
- 1.3 坐标及其命名规范
- 1.4 仓库的概念
- 1.5 生命周期
- 1.6 插件和目标
- 二、依赖管理
- 2.1 自己写的模块和模块之间也可以互相依赖
- 2.2 依赖的生效范围(scope标签)
- 2.3 依赖的传递性
- 2.4 依赖冲突问题
- 2.5 依赖的排除
- 2.6 依赖版本统一管理
- 三、继承
- 3.1 手动更改配置文件
- 3.2 使用IDEA自动继承
- 四、聚合
- 4.1 问题引入
- 4.2 解决方案
前言
上一章的学习已经足够掌握对Maven的基本使用了
而本章节对Maven的深入了解即使不掌握也不影响Maven的使用
不过经过本章更细节的学习
在往后使用Maven出现的小问题 可以更快速的定位问题所在
一、Maven的核心概念
1.1 Maven-Jar包+模块化管理
Maven的两大主要功能就是:
- 管理Jar包
- 模块化管理项目
1.2 POM
本质就是面向对象/模块化的思想
Maven主要就两个点:
第一是对jar包的各种管理
第二是对项目的管理(把项目拆分成各个模块项目进行管理)
1.3 坐标及其命名规范
- 数学中,在平面上xy能确定一个唯一的点;在空间上xyz能确定一个唯一的点
- 类似的,在Maven中的坐标也是这个作用,确定该项目/模块的唯一路径
这里用install自己的模块到本地仓库为例:
- 命名规范:
groupId:公司或者组织的域名的倒序+当前项目/模块名称
artifactId:当前项目/模块的名称
version:当前项目/模块的版本号
1.4 仓库的概念
事实上 在实际工作中 本地仓库和中央仓库之间还存在一个私服
也就是公司为了方便统一管理 自己搞得私人服务器
由公司统一从中央仓库下载 员工在个人电脑上配置公司私服的地址
这样做主要就是为了公司能统一管理
1.5 生命周期
clean default site
1.6 插件和目标
刚刚说Maven生命周期 那么多的功能 实际上都是有插件完成的
而Maven的核心仅仅是定义了生命周期
目标可以理解成任务
任务和插件的关系是一对多
二、依赖管理
2.1 自己写的模块和模块之间也可以互相依赖
因为我之前已经对Test02进行过install操作
所以直接测试 是没什么问题的
看看我把Test02在本地仓库的Jar删除会发生什么
2.2 依赖的生效范围(scope标签)
- compile(默认就是这个范围)
1.main目录下的Java代码可以访问这个范围的依赖
2.test目录下的Java代码可以访问这个范围的依赖
3.部署到Tomcat服务器上运行时 要放在WEB-INF的lib目录下(简单的理解成部署出去的肯定是给用户使用的 用的就是主程序的代码 所以肯定要放)
列如上面的Junit 我没有写任何scope标签 所以是默认的compile
那么我无论是在主程序里importJunit还是在测试程序里importJunit 都不会报错
-
test
1.main目录下的Java代码不能访问这个范围的依赖
2.test目录下的Java代码可以访问这个范围的依赖
3.部署到Tomcat服务器上运行时不会放在WEB-INF的lib目录下(测试程序 我当然不需要部署 这对用户来说是无关紧要的) -
provided(生效范围和compile一致)
1.main目录下的Java代码可以访问这个范围的依赖
2.test目录下的Java代码可以访问这个范围的依赖
3.部署到Tomcat服务器上运行时不会放在WEB-INF的lib目录下
因为Tomcat也是用Java写的 他所依赖的Jar包肯定是自带的
而我的项目如果用到了相同的Jar包 直接用Tomcat的就行了
例如:servlet-api在服务器上运行时,Servlet容器会提供相关API,所以部署的时候不需要
2.3 依赖的传递性
2.4 依赖冲突问题
Maven自动会根据以下两点原则帮助我们处理依赖冲突问题
1.路径最短者优先
2.路径相同时先声明者优先
注:这里的声明指的是父模块对于依赖子模块的声明
如果在MakeFried里先声明对HelloF的依赖 那就传递2.14
反之传递2.17
2.5 依赖的排除
比如:
03依赖了02 02依赖了Junit4.5
根据依赖传递原则 Junit4.5会传递给03
但是03不想要4.5 想自己依赖一个4.9
如何解决?
排除之后 我想依赖谁自己添加即可
2.6 依赖版本统一管理
以Spring全家桶为例
当我引入一大堆依赖的时候 肯定希望版本是统一的
同时也不希望在不统一的情况下一个一个去改版本
这个时候就有了之前的约定>配置>编码的思想
那我能不能把版本号提取出来成一个配置 然后直接引用呢?
牵一发则动全身
三、继承
3.1 手动更改配置文件
注意:这里容易混淆
在2.6不是提到了统一管理吗
为什么这里又搞出来一个继承?
2.6的统一管理 是针对在同一个Maven项目里需要多个依赖
这里继承是针对多个Maven项目里来统一管理依赖
其中 父工程他其实没必要打成jar包
因为他的作用就是给子工程去继承使用
方便统一管理的
真正有用的 要打包成jar的 就是子工程
1.首先在父工程声明一下打包方式
2.然后在每一个子工程的pom文件里实现继承
3.最后为了统一管理子工程依赖版本号 需要在父工程的pom里设置
3.记住如果需要使用父类统一的版本 需要在子类直接把依赖的版本坐标删掉就行(否则就类似于子类重写了父类方法 肯定优先使用子类的方法)
4.上面那种方式父工程里并不会加载所写的依赖 仅仅是统一管理了版本
而这种方式 父类会加载junit 同时子类会直接继承并加载junit 都不需要写dependency
3.2 使用IDEA自动继承
四、聚合
4.1 问题引入
聚合的前提是有继承关系
HelloF依赖Hello
我想打包HelloF之前 必须先把Hello install到本地仓库才行
否则会报错
如果存在大量的依赖
每次都要我一个一个去找去install 岂不是非常低效率?
4.2 解决方案
聚合的配置很简单
这样一来 问题就解决了
而且MAVEN先后顺序都考虑到了
别说是package 直接install Parent都可以!!