面試官居然和我死磕 Maven

引言

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，禁止在子項目中單獨聲明要發佈或者依賴的二方包

面試官 👨‍： 不錯不錯，小夥子明天來上班吧

小明 🤪：好嘞

---

文章結束，若是本文對你有所幫助的話，那就點個贊吧

想要了解更多的分享，能夠關注一下公衆號

公衆號回覆 「資料」 能夠獲取大廠面試題/技術文檔/電子書等等

---

往期推薦

3 分鐘簡單理解橋接模式 來自大廠的11條異常最佳實踐 工廠設計模式，這幾個問題你知道嗎？