共计 2773 个字符,预计需要花费 7 分钟才能阅读完成。
引言
Maven 是 Apache 软件基金会惟一保护的一款自动化构建工具,专一于服务 Java 平台的我的项目构建和依赖治理。
先来问问本人几个问题
Maven 的依赖寻找程序、scope 范畴、生命周期、依赖准则、如何解决依赖抵触、为何不让自定义二方包版本号,如果你能顺利的答复进去,那么快点个赞再进来。🤭
如果你只是含糊其辞,那么能够看看上面的文章,(题目均来自网友实在的面试题)
依赖寻找程序
面试官 👨:先来一道小题热热身,Maven 是如何寻找依赖的?
小明 🤪:首先会去 本地仓库 寻找,而后会去公司的 私服仓库 寻找,个别私服仓库存的都是公司本人开发的 jar 包,最初会去 由 Apache 团队来保护 地方仓库 寻找,一旦在一个中央找到就不再寻找。面试官,加点难度啊。太简略
面试官 👨:小伙子,很飘啊,那我接着问你,咱们 pom 文件具备许多标签,不少同学对各种标签和应用混淆不清,先来问你常见的几个标签的作用
小明 🤪:放马过来
如何确认这个依赖的惟一示意
面试官 👨:在咱们我的项目中具备泛滥依赖,程序是如何确定这个依赖的地位呢?
小明 🤪:这个简略
通常状况下,咱们利用 groupId、artifactId、version 标签来确认这个依赖的惟一坐标
<groupId>:企业网址反写 + 我的项目名
<artifactId>:我的项目名 - 模块名
<version>:以后版本
<groupId>com.juejin.business</groupId>
<artifactId>juejin-image-web</artifactId>
<version>1.0.0-SNAPSHOT</version>
scope 范畴有哪些
面试官 👨:scope 标签在咱们的我的项目中常常应用到,你晓得常见的范畴有哪些吗?
小明 🤪:这个难不倒我
咱们罕用的 scope 的范畴是
compile | test | provided | |
---|---|---|---|
主程序 | √ | x | √ |
测试程序 | √ | √ | √ |
参加部署 | √ | x | x |
- compile:默认范畴,编译、测试、运行都无效
- provided:编译和测试无效,最初运行不会被退出,如 tomcat 依赖
- runtime:在测试和运行的时候无效,编译不会被退出,比方 jdbc 驱动 jar
- test:测试阶段无效,比方 junit
- system:与 provided 统一,编译和测试阶段无效,但与零碎关联,可移植性差
- import:导入的范畴,它只是用在 dependencyManagement 中,示意从其它的 pom 中导入 dependency 的配置
scope 的依赖是如何传递的
面试官 👨:答复的不错,那么如果我的项目 A 依赖 我的项目 B 的范畴为 provided,我的项目 B 依赖 我的项目 C 的范畴为 runtime 的,最终我的项目 A 依赖我的项目 C 的范畴为什么?
小明 🤪:依赖的范畴为 provided 让我画个图给你看
如何排除依赖
面试官 👨:在咱们引入许多依赖之后,大概率会产生依赖抵触,你是如何解决的?
小明 🤪:假如 juejin-convert-web 这个依赖产生了抵触,我会这样解决,首先找到抵触我的项目
1- 通过 exclusions 标签实现。抵触我的项目依赖
juejin-image-web 我的项目的时候,被动排除传递的 juejin-convert-web 我的项目依赖
<dependency>
<groupId>com.juejin.business</groupId>
<artifactId>juejin-image-web</artifactId>
<version>1.0.0-SNAPSHOT</version>
<exclusions>
<exclusion>
<groupId>com.juejin.business</groupId>
<artifactId>juejin-convert-web</artifactId>
</exclusion>
</exclusions>
</dependency>
2- 通过 optional 实现
批改 juejin-image-web 我的项目的 pom.xml:
<dependency>
<groupId>com.juejin.business</groupId>
<artifactId>juejin-convert-web</artifactId>
<version>1.0.0-SNAPSHOT</version>
<optional>true</optional>
</dependency>
依赖传递准则
面试官 👨:看你对 Maven 的依赖传递是有肯定理解的,你具体说说这个 Maven 依赖传递的准则。
小明 🤪:好,Maven 依赖传递的准则有两点,第一点是 最短门路准则 ,第二点是 最先申明准则
举个例子阐明
a->b->c(2.0)
a->c(1.0)
最初采取 c(1.0) 这个版本,因为它短啊。
再来个例子阐明一下第二个准则
a->b->c(2.0)
a->d->c(1.0)
因为 b 先申明引入了 c,所以采取 c(2.0)
当然如果咱们在 a 中间接依赖了 c 必定是以咱们 a 的我的项目依赖的 c 版本为主,远亲准则
Maven 的生命周期
面试官 👨:Maven 有三套互相独立的生命周期,别离是,Clean Lifecycle 在进行真正的构建之前进行一些清理工作,Default Lifecycle 构建的外围局部,编译,测试,打包,装置,部署等等,Site Lifecycle 生成我的项目报告,站点,公布站点,并且在 idea 的侧边栏你也能够看到
你开展讲讲这些生命周期做了什么事?
小明 🤪:好
clean 移除所有上一次构建生成的文件
validate:验证工程是否正确,所有须要的资源是否可用
compile:编译我的项目的源代码
test:应用适合的单元测试框架来测试已编译的源代码。这些测试不须要已打包和布署。package:把已编译的代码打包成可公布的格局,比方 jar、war 等。verify:运行所有查看,验证包是否无效且达到质量标准。install:把包装置到 maven 本地仓库,能够被其余工程作为依赖来应用
site 生成我的项目的站点文档
deploy:在集成或者公布环境下执行,将最终版本的包拷贝到近程的 repository,使得其余的开发者或者工程能够共享
在子项目中任意定义二方包版本号
面试官 👨:咱们新来的一个实习生,在子项目中随便定义了一个二方包的版本号,你感觉合不适合,
小明 🤪:不大适合,因为在咱们合作开发同一个利用的时候,如果大家都随便批改二方包的版本号,那么分支合并的时候肯定抵触,同时援用这个二方包的我的项目也肯定会抵触,
所以咱们包的版本治理都交由主 POM,禁止在子项目中独自申明要公布或者依赖的二方包
面试官 👨:不错不错,小伙子今天来下班吧
小明 🤪:好嘞
文章完结,如果本文对你有所帮忙的话,那就点个赞吧
想要理解更多的分享,能够关注一下公众号
公众号回复“材料”能够获取大厂面试题 / 技术文档 / 电子书等等