引言

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 的范畴是

compiletestprovided
主程序√x√
测试程序√√√
参加部署√xx
  • 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，禁止在子项目中独自申明要公布或者依赖的二方包

面试官 ： 不错不错，小伙子今天来下班吧

小明 ：好嘞

文章完结，如果本文对你有所帮忙的话，那就点个赞吧

想要理解更多的分享，能够关注一下公众号

公众号回复 “材料” 能够获取大厂面试题/技术文档/电子书等等