Maven深入了解

朱一头zcy

已于 2024-03-12 15:41:18 修改

阅读量1k

点赞数 14

分类专栏： # Maven 文章标签： maven

于 2024-03-11 16:06:50 首次发布

本文链接：https://blog.csdn.net/qq_57030936/article/details/136617159

版权

Maven 专栏收录该内容

4 篇文章 1 订阅

订阅专栏

前言

上一章的学习已经足够掌握对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
在这里插入图片描述