前言

我們?cè)谌粘５膉avaee項(xiàng)目開發(fā)中，對(duì)于大量模塊的開發(fā)管理和jar包的管理，我們難免會(huì)設(shè)計(jì)到maven進(jìn)行項(xiàng)目的管理，這里我總結(jié)Maven中比較重要的一些知識(shí)點(diǎn)，這也是我在最近學(xué)習(xí)的項(xiàng)目谷粒學(xué)院中所感覺到Maven的使用重要性，所以我就對(duì)maven中的一些比較重要的知識(shí)點(diǎn)記性總結(jié)，希望可以為正在學(xué)習(xí)的小伙伴提供一些幫助。
“最后希望小伙伴留下小小的愛心”

導(dǎo)言

在我們的生產(chǎn)環(huán)境中，開發(fā)不再是一個(gè)項(xiàng)目一個(gè)工程，而是每一個(gè)模塊創(chuàng)建一個(gè)工程，而多個(gè)模塊整合在一起就需要使用Maven這樣的構(gòu)建工具。

我們真的需要Maven嗎？

真的需要Maven嗎？相信小伙伴在學(xué)習(xí)Maven的時(shí)候可能會(huì)問自己這個(gè)問題，Maven是干什么用的？為什么這里我們需要用到Maven？不用Maven我們會(huì)有什么麻煩？之所以會(huì)提出這個(gè)問題是因?yàn)槲覀兗词共皇褂肕aven我們?nèi)稳豢梢赃M(jìn)行B/S結(jié)構(gòu)項(xiàng)目的開發(fā)。只是比較麻煩而已，就像我們旅游？不一定非要坐飛機(jī)，我們坐火車也可以去，只是時(shí)間效率不同而已。

從表述層、業(yè)務(wù)邏輯層到持久層再到數(shù)據(jù)庫都有成熟的解決方案—不使用Maven我們一樣也可以進(jìn)行項(xiàng)目的開發(fā)。

這里可能我們的思想會(huì)有一個(gè)誤區(qū)，Maven并不是直接用來輔助編碼的，他戰(zhàn)斗的崗位并不是以上各層。所以我們有必要通過企業(yè)開發(fā)中的實(shí)際需求來看看那些方面是我們現(xiàn)有技術(shù)的不足。

2.2 歸其原因，為什么要用Maven？

Maven能夠幫助我們提高開發(fā)效率，但是他能幫我們解決什么問題呢？

①：幫助我們添加第三方j(luò)ar包

在我們今天企業(yè)的javaee開發(fā)領(lǐng)域中，有大量的第三方框架和工具可以供我們使用，要使用這些jar包最簡(jiǎn)單的方法就是復(fù)制粘貼到我們web工程下的WEB-INF/lib目錄下。但是這會(huì)導(dǎo)致每次創(chuàng)建一個(gè)新的工程就需要將jar包重復(fù)復(fù)制到lib目錄下，從而會(huì)造成我們的工作區(qū)間存在大量的重復(fù)文件，讓我們的工程會(huì)顯得很臃腫。而使用Maven后每個(gè)jar包本身值在本地創(chuàng)庫中保存一份，需要jar包的工程只需要一坐標(biāo)的方式簡(jiǎn)單的引用一下就可以了。不僅極大的節(jié)約了存儲(chǔ)空間，讓項(xiàng)目更加輕巧，更加避免了重復(fù)文件太多而造成的混亂。

②： jar包之間的依賴關(guān)系

我們?cè)陂_發(fā)工程的時(shí)候需要用的別的jar包，簡(jiǎn)而言之那別人在開發(fā)的時(shí)候也有可能需要使用到別的jar包，所以以此類推就會(huì)出現(xiàn)一種情況就是jar包依賴的情況。也及時(shí)我們的jar包不是孤立存在的，很多jar包都需要在其他jar包的支持下才能夠正常工作，我們稱之為jar包之間的依賴關(guān)系。其中比較典型的就是我們的文件上傳操作，我們?cè)谑褂胏ommons-fileupload-1.3.jar 就依賴于 commons-io-2.0.1.jar，如果沒有后面的包，我們的文件上傳功能也就無法實(shí)現(xiàn)。那么問題來了，你知道你所使用的所有jar包依賴哪些包嗎？當(dāng)你拿到一個(gè)新的從未使用過jar包，你如何得知他需要那些jar包的支持？如果不了解情況的話，導(dǎo)入的jar包不夠，那么現(xiàn)有的程序還是不能夠正常運(yùn)行。再進(jìn)一步，當(dāng)你的項(xiàng)目中需要用到上百的個(gè)jar包時(shí)，你還會(huì)人為的，手工的逐一確認(rèn)他們一來的其他jar包嗎？這簡(jiǎn)直就是一筆大工程。而引入Maven后，Maven就可以替我們自動(dòng)的將當(dāng)前jar包所依賴的其他所有jar包全部導(dǎo)入過來，無需人工參與，節(jié)約了我們大量的時(shí)間和精力。用實(shí)際的例子來說明就是：通過Maven導(dǎo)入commons-fileupload-1.3.jar 后，，commons-io-2.0.1.jar 會(huì)被自動(dòng)導(dǎo)入，程序員不必了解這個(gè)依賴關(guān)系。下圖就是spring所需jar包的部分依賴關(guān)系

③：獲取第三方j(luò)ar包

在javaee的開發(fā)中需要使用jar包種類繁多，幾乎每個(gè)jar包在其本身的官網(wǎng)上獲取方式都不盡相同。為了查找一個(gè)jar包我們需要找遍互聯(lián)網(wǎng)，身心俱疲，沒有經(jīng)歷過的人或許體會(huì)不到這種折磨。不僅如此，費(fèi)勁心力找的jar包里有的時(shí)候并沒有你需要的那個(gè)類，又或許有你要的類又沒有你要的方法---以不規(guī)范的方式獲取的jar包往往也是不規(guī)范的。使用maven我們可以享受到一個(gè)完全同意規(guī)范的jar包管理體系。你只需要在你的項(xiàng)目已坐標(biāo)的方式依賴一個(gè)jar包，Maven就會(huì)自動(dòng)從中央倉庫進(jìn)行下載，并同下載這個(gè)jar包所依賴的其他所有jar包------規(guī)范、完整、準(zhǔn)確、一次性解決所有問題！

PS：在這里我們順便說一下，統(tǒng)一的規(guī)范可以說成是程序員的最高信仰。如果沒有一個(gè)統(tǒng)一的規(guī)范，就會(huì)意味著每個(gè)具體的技術(shù)都各自為政，需要以諸多不同的特殊方式加入到我們的項(xiàng)目中；好不容易加入進(jìn)來還會(huì)和其他技術(shù)格格不入，最終受苦的還是我們開發(fā)人員。而任何一個(gè)領(lǐng)域的統(tǒng)一規(guī)范都能夠極大的降低程序員的工作難度，減少工作量。例如：USB接口可以外接各種設(shè)備，如果每個(gè)設(shè)備都有自己獨(dú)特的接口，那么不僅制造商需要維護(hù)各個(gè)接口的設(shè)計(jì)方案，使用者也需要了解每個(gè)設(shè)備對(duì)應(yīng)的接口，無疑是非常繁瑣的。

④：將項(xiàng)目拆分成多個(gè)工程模塊

隨著javaee項(xiàng)目的規(guī)模越來越大，開發(fā)團(tuán)隊(duì)的規(guī)模也與日俱增，一個(gè)項(xiàng)目上千人的團(tuán)隊(duì)持續(xù)開發(fā)很多對(duì)于javaee項(xiàng)目來說是再正常不過了。如果幾百人上千人的開發(fā)項(xiàng)目是同一個(gè)web工程。那么架構(gòu)師、項(xiàng)目經(jīng)理該如何劃分項(xiàng)目的模塊、如何進(jìn)行分工呢？這么大的項(xiàng)目已經(jīng)不可能通過package結(jié)構(gòu)來劃分模塊，必須將項(xiàng)目拆分成多個(gè)工程協(xié)同開發(fā)。多個(gè)模塊工程中有的是java項(xiàng)目，有的是web項(xiàng)目。那么工程拆分后又該如何進(jìn)行項(xiàng)目調(diào)和訪問呢？這就需要用到maven的依賴管理機(jī)制。大家可以看一下survey調(diào)查項(xiàng)目的拆分情況。

3 . Maven核心講解

3.1 maven簡(jiǎn)介

Maven是Apache軟件基金會(huì)組織維護(hù)的一款自動(dòng)化構(gòu)建工具，專注服務(wù)于java平臺(tái)的項(xiàng)目構(gòu)建和項(xiàng)目依賴管理。Maven這個(gè)單詞的本意是：“專家，內(nèi)行”。

3.2 什么是構(gòu)建

構(gòu)建并不是創(chuàng)建，創(chuàng)建一個(gè)工程并不等于構(gòu)建一個(gè)項(xiàng)目。要了解構(gòu)建的含義我們應(yīng)該由淺入深的從以下三個(gè)層面來看：

①：純Java代碼

小伙伴都知道，我們Java是一門編譯型語言，純Java擴(kuò)展名的源文件需要編譯成。class擴(kuò)展名的字節(jié)碼文件才能夠執(zhí)行。所以編寫任何Java代碼想要執(zhí)行的話就必須編譯成對(duì)應(yīng)的.class文件

②：web工程

當(dāng)我們需要通過瀏覽器訪問java程序時(shí)就必須將包含java程序的web工程編譯的結(jié)果“拿”到服務(wù)器上的指定目錄下，并啟動(dòng)服務(wù)器才行。這個(gè)“拿”的工程我們叫部署。我們可以將未編譯的web工程比喻成一只生的雞，編譯好的web工程是一只煮熟的雞，編譯部署的過程就是將雞煮熟的過程。web工程和其編譯結(jié)果的目錄結(jié)構(gòu)對(duì)比見下圖：

③：實(shí)際項(xiàng)目

在實(shí)際項(xiàng)目中整合第三方框架，web工程中除了Java程序和jsp頁面、圖片等靜態(tài)資源之外，還包括第三方框架的jar包以及各種各樣的配置文件。所有這些資源都必須按照正確的目錄結(jié)構(gòu)部署到服務(wù)器上，項(xiàng)目才可以運(yùn)行。所以綜上所述：構(gòu)建就是以我們編寫的java代碼、框架配置文件、國家化等其他資源文件、jsp頁面和圖片等靜態(tài)資源作為“原材料”，去“生產(chǎn)”一個(gè)可以運(yùn)行的項(xiàng)目的過程。那么項(xiàng)目的構(gòu)建過程包含哪些環(huán)節(jié)呢？

3.3 構(gòu)建過程的幾個(gè)主要環(huán)節(jié)

• 清理：刪除以前的編譯結(jié)果，為重新編譯做好準(zhǔn)備
• 編譯：將Java源程序編譯成可執(zhí)行的字節(jié)碼文件。
• 測(cè)試：針對(duì)項(xiàng)目中的關(guān)鍵點(diǎn)進(jìn)行測(cè)試，確保項(xiàng)目在迭代開發(fā)過程中關(guān)鍵點(diǎn)的正確性。
• 報(bào)告：在每一次測(cè)試后以標(biāo)準(zhǔn)的格式記錄和展示測(cè)試結(jié)果
• 打包：將一個(gè)包含諸多文件的工程封裝為一個(gè)壓縮文件用于安裝或部署。java工程對(duì)應(yīng)的jar包，web工程對(duì)應(yīng)的war包
• 安裝：在Maven環(huán)境下特指將打包的結(jié)果—jar包或war包安裝到本地倉庫中
• 部署：將打包的結(jié)果部署到遠(yuǎn)程倉庫或?qū)ar包部署到服務(wù)器上運(yùn)行。

3.4 自動(dòng)化構(gòu)建

其實(shí)上述環(huán)節(jié)我們?cè)趀clipse中都可以找到對(duì)應(yīng)的操作，只是不太標(biāo)準(zhǔn)。那么既然ide以及可以進(jìn)行構(gòu)建了，我們?yōu)槭裁催€要使用Maven這樣的構(gòu)建工具呢？我們來看一個(gè)小故事：

這是陽光明媚的一天，托馬斯像往常一樣早早的來到公司，沖好了一杯咖啡，進(jìn)入自己的郵箱---很不幸，QA小姐發(fā)來了一封郵件，報(bào)告了他昨天提交的模塊測(cè)試結(jié)果--有bug。“好吧，反正也不是第一次”，托馬斯搖搖頭，進(jìn)入IDE，運(yùn)行自己的程序，編譯打包。部署到服務(wù)器上，然后按照郵件中的操作路徑進(jìn)行測(cè)試。“嗯，沒錯(cuò)，這個(gè)地方確實(shí)有問題”，托馬斯說道。于是托馬斯開始嘗試修復(fù)這個(gè)bug，當(dāng)他差不多有眉目的時(shí)候已經(jīng)到了午飯的時(shí)間。下午繼續(xù)工作，bug很快就被修正了，接著托馬斯對(duì)模塊重新進(jìn)行了編譯，打包、部署、測(cè)試之后確認(rèn)沒有問題了，回復(fù)了QA小姐的郵件。一天就這樣過去了，明媚的陽光化作了美麗的晚霞，托馬斯卻覺得生活并不像晚霞那樣美好。

讓我們來梳理一下托馬斯這一天中的工作內(nèi)容

從中我們可以發(fā)現(xiàn)，托馬斯的很大一部分時(shí)間都發(fā)在“編譯、打包、部署、測(cè)試”，這些程式化的工作上面，而真正需要由“人”的智慧實(shí)現(xiàn)的分析問題和編碼卻只占了很少的一部分。

能否將這些程式化的工作直接交給機(jī)器自動(dòng)完成呢？----當(dāng)然可以！這就是自動(dòng)化構(gòu)建

此時(shí)Maven的意義就體現(xiàn)出來了，他可以自動(dòng)的從構(gòu)建過程的起點(diǎn)一直執(zhí)行到終點(diǎn)：

3.5 Maven核心概念

Maven能夠?qū)崿F(xiàn)自動(dòng)化構(gòu)建是和它的內(nèi)部原理分不開的，這里我們從maven的九個(gè)核心概念入手，看看Maven是如何實(shí)現(xiàn)自動(dòng)化構(gòu)建的

• POM
• 約定的目錄結(jié)構(gòu)
• 坐標(biāo)
• 依賴管理
• 倉庫管理
• 生命周期
• 插件和目標(biāo)
• 繼承
• 聚合

4 HOW

Maven的核心程序中僅僅定義了抽象的生命周期，而具體的操作則是由Maven的插件來完成的，可是Maven的插件并不包含在Maven的核心程序中，在首次使用時(shí)需要聯(lián)網(wǎng)下載。

5 Maven核心概念

5.1 POM

Project Object Model:項(xiàng)目對(duì)象模型。將Java工程的相關(guān)信息封裝為對(duì)象作為便于操作和管理的模型，Maven工程的核心配置，可以說是學(xué)習(xí)maven就是學(xué)習(xí)pom.xml文件中的配置。

5.2 約定的目錄結(jié)構(gòu)

約定的目錄結(jié)構(gòu)對(duì)于maven實(shí)現(xiàn)自動(dòng)化構(gòu)建而言是必不可少的一環(huán)，就拿自動(dòng)化編譯來說，maven必須能找到j(luò)ava源文件，下一步才能編譯，而編譯之后也必須有一個(gè)準(zhǔn)確的位置保持編譯得到的字節(jié)碼文件。我們?cè)陂_發(fā)中如果需要讓第三方工具或框架知道我們自己創(chuàng)建的資源在哪，那么基本上就是兩種方式：

①：通過配置的形式明確告訴它

②：基于第三方工具或框架的約定

maven對(duì)于工程目錄結(jié)構(gòu)的要求就屬于后面的一種。

現(xiàn)在javaee開發(fā)領(lǐng)域普遍認(rèn)同同一個(gè)觀點(diǎn)：約定>配置>編碼。意思就是能用配置解決的問題就不編碼，能基于約定的就不進(jìn)行配置。而Maven正是因?yàn)橹付颂囟ㄎ募４娴哪夸洸拍軌驅(qū)ξ覀兊膉ava工程進(jìn)行自動(dòng)化構(gòu)建。

5.3 坐標(biāo)

①：幾何中的坐標(biāo)

• 在一個(gè)平面中使用x，y兩個(gè)向量可以唯一的確定平面中的一個(gè)點(diǎn)。
• 在空間中使用x,y,z三個(gè)向量可以唯一的確定空間中的一個(gè)點(diǎn)

②：maven的坐標(biāo)

使用如下三個(gè)向量在maven的倉庫中唯一的確定一個(gè)Maven工程

• groupid：公司或組織的域名倒序+當(dāng)前項(xiàng)目名稱
• artifactld：當(dāng)前項(xiàng)目的模塊名稱
• version：當(dāng)前模塊的版本

③：如何通過坐標(biāo)到倉庫中查找對(duì)應(yīng)的jar包？

• 將gav三個(gè)向量連起來

• 已連起來的字符串作為目錄結(jié)構(gòu)到倉庫中查找

5.4 依賴

maven中最關(guān)鍵的部分，我們使用Maven最重要的就是使用他的依賴管理功能。要理解和掌握Maven的依賴管理，我們只需要解決一個(gè) ①：依賴的目的是什么？

當(dāng)A jar包用到了B jar包中的某些類時(shí)，A就對(duì)B產(chǎn)生了依賴，這是概念上的描述。那么如何在項(xiàng)目中一依賴的方式引入一個(gè)我們需要的jar包呢？

答案非常簡(jiǎn)單，就是使用depenency標(biāo)簽指定被依賴包的坐標(biāo)就可以了。

②：依賴的范圍

大家注意到上面的依賴信息中除了目標(biāo)jar包的坐標(biāo)以外還有一個(gè)scope設(shè)置，這是依賴的范圍。依賴的范圍有幾個(gè)可選值，我們用得到的是：complie、test、provided三個(gè)。

結(jié)合具體的例子：對(duì)于helloFriend來說，hello 就是服務(wù)于主程序的，junit就是服務(wù)于測(cè)試程序的。helloFriend 主程序需要hello 是非常明顯的，測(cè)試程序由于要調(diào)用主程序所以也需要hello，所以complie范圍依賴對(duì)于主程序和測(cè)試程序都應(yīng)該有效。

• 從開發(fā)和運(yùn)行這兩個(gè)不同階段理解complie和provided的區(qū)別

③：有效性總結(jié)

④：依賴的傳遞性

A依賴B,B依賴C,A能否使用C呢？那么我們就要看B依賴C的范圍是不是complie，否則不可用。

依賴的排出

如果我們?cè)诋?dāng)前工程中引入了一個(gè)依賴是A，而A又依賴了B，那么Maven會(huì)自動(dòng)將A依賴的B引入當(dāng)前工程，但是個(gè)別情況下B有可能是一個(gè)不穩(wěn)定版本，或?qū)Ξ?dāng)前工程有不良影響。這是我么可以在引用A的時(shí)候?qū)排除。

• 情景舉例

• 配置方式

• 排除后的效果

5.5 統(tǒng)一管理所依賴jar包的版本

對(duì)同一個(gè)框架的一組jar包最好使用相同的版本。為了方便升級(jí)框架，可用將jar包的版本信息統(tǒng)一提取出來

• 統(tǒng)一聲明版本號(hào)

其中atguigu.spring.version不是是自定義標(biāo)簽

• 引用前面聲明的版本號(hào)

• 其他用法

5.5 倉庫

①：分類

本地倉庫：為當(dāng)前本機(jī)電腦上的所有Maven工程服務(wù)遠(yuǎn)程倉庫：私服：架構(gòu)在當(dāng)前局域網(wǎng)環(huán)境下，為當(dāng)前局域網(wǎng)范圍內(nèi)的所有Maven工程服務(wù)。

中央倉庫：架構(gòu)在internet上，為全世界所有的Maven工程服務(wù)

中央倉庫的鏡像：架設(shè)在各大洲，為中央倉庫分擔(dān)流量。減輕中央倉庫的壓力，同時(shí)更快的響應(yīng)用戶的請(qǐng)求。

②：倉庫中的文件

maven的插件我們自己開發(fā)的項(xiàng)目的模塊第三方框架或工具的jar包

不管是什么樣的jar包，在倉庫中都是按照坐標(biāo)生成目錄結(jié)構(gòu)，所以可以通過統(tǒng)一的方式查詢依賴。

5.6 生命周期

①：什么是Maven的什么周期？

• Maven生命周期定義了各個(gè)構(gòu)建環(huán)節(jié)的執(zhí)行順序，有了這個(gè)清單，Maven就可以自動(dòng)化的執(zhí)行構(gòu)建命令了。

• Maven有三套相互獨(dú)立的生命周期，分別是：

  ①：clean Lifecycle 在進(jìn)行真正構(gòu)建之前進(jìn)行一些清理工作②：Default Lifecycle 構(gòu)建的核心部分，編譯，測(cè)試，打包，安裝，部署等等③：site Lifecycle 生成報(bào)告，站點(diǎn)，發(fā)布站點(diǎn)

他們是相互獨(dú)立，你可以僅僅調(diào)用clean來清理工作目錄，僅僅調(diào)用site來生成站點(diǎn)。當(dāng)然也可以直接運(yùn)行mvn clean install site 運(yùn)行所有這三套什么周期。

每套生命周期都由一組階段組成，我們平時(shí)在命令行輸入的命令總會(huì)對(duì)應(yīng)一個(gè)特定的階段。比如，運(yùn)行mvn clean，這個(gè)clean是clean生命周期，也有clean階段。

②：clean什么周期

clean生命周期一共包含三個(gè)階段：①:pre-clean 執(zhí)行一些需要在clean之前完成的工作②：clean 移除所有上一次構(gòu)建生成的文件③：post-clean執(zhí)行一些需要在clean之后立刻生成的工作

③：site生命周期

①：pre-site 執(zhí)行一些需要在生成站點(diǎn)文檔之前完成的工作②：site 生成項(xiàng)目的站點(diǎn)文檔③：post-site 執(zhí)行一些需要在生成站點(diǎn)文檔之后完成的工作，并且為部署做準(zhǔn)備④：site-deploy將生成的站點(diǎn)文檔部署到特定的服務(wù)器上

這里經(jīng)常用到的是site階段和site-deploy階段，用以生成和發(fā)布Maven站點(diǎn)，這可是maven相當(dāng)大的功能，manager比較喜歡，文檔及統(tǒng)計(jì)數(shù)據(jù)自動(dòng)生成很好看。

④：Default生命周期

Default生命周期是maven生命周期中最重要的一個(gè)，絕大部分工作都發(fā)生在這個(gè)生命周期中，這里，只解釋一些比較重要和常用的階段：

validate

generate-sources

process-sources

generate-resources

process-resources 復(fù)制并處理資源文件，至目標(biāo)目錄，準(zhǔn)備打包。

compile 編譯項(xiàng)目的源代碼

process-classes

generate-test-sources

process-test-sources

generate-test-resources

process-test-resources 復(fù)制并處理資源文件，至目標(biāo)測(cè)試目錄。

test-compile 編譯測(cè)試源代碼。

process-test-classes

test 使用合適的單元測(cè)試框架運(yùn)行測(cè)試。這些測(cè)試代碼不會(huì)被打包或部署。

prepare-package

package 接受編譯好的代碼，打包成可發(fā)布的格式，如 JAR

pre-integration-test

integration-test

post-integration-test

verify

install 將包安裝至本地倉庫，以讓其它項(xiàng)目依賴

deploy 將最終的包復(fù)制到遠(yuǎn)程的倉庫，以讓其它開發(fā)人員與項(xiàng)目共享或部署到服務(wù)器上運(yùn)行

⑤：生命周期與自動(dòng)化構(gòu)建

運(yùn)行任何一個(gè)階段的時(shí)候，他前面的所有階段都會(huì)被運(yùn)行，例如我們運(yùn)行mvn install的時(shí)候，代碼會(huì)被編譯，測(cè)試，打包。這就是Maven為什么能夠自動(dòng)執(zhí)行構(gòu)建過程的各個(gè)環(huán)節(jié)的原因。此外，Maven的插件機(jī)制是完全依賴Maven的生命周期的，因此理解生命周期是至關(guān)重要。

5.7 插件和目標(biāo)

• Maven的核心僅僅定義了抽象的生命周期，具體的任務(wù)都是交由插件完成的
• 每個(gè)插件都可以實(shí)現(xiàn)多個(gè)功能，每個(gè)功能就是一個(gè)插件
• Maven的生命周期與插件目標(biāo)相互綁定以完成某個(gè)具體的構(gòu)建任務(wù)

例如：compile就是插件maven-compli-plugin的一個(gè)目標(biāo)：pre-clean是插件maven-clean-plugin的一個(gè)目標(biāo)。

5.8 繼承

①：為什么需要繼承機(jī)制

由于非complie范圍的依賴信息是不能在“依賴鏈”中傳遞的，所以有需要的工程只能單獨(dú)配置。例如

此時(shí)如果項(xiàng)目需要將各個(gè)模塊的junit版本統(tǒng)一為5.9，那么到各個(gè)工程手動(dòng)修改無疑是非常不可取的。使用繼承機(jī)制就可以將這樣的依賴信息統(tǒng)一提取到父工程模塊中進(jìn)行統(tǒng)一管理。

②：創(chuàng)建父工程

創(chuàng)建父工程和創(chuàng)建一般的Java工程操作一樣，唯一需要注意的就是：打包方式初要設(shè)置為pom

③：在子工程中引用父工程

<parent> <!-- 父工程坐標(biāo) --><groupId>...</groupId> <artifactId>...</artifactId> <version>...</version> <relativePath>從當(dāng)前目錄到父項(xiàng)目的 pom.xml 文件的相對(duì)路徑</relativePath> </parent>

此時(shí)如果子工程的groupid和version如果和父工程重復(fù)則可以刪除。

④：在父工程中管理依賴

將parent項(xiàng)目中的dependencies標(biāo)簽，用dependencyManagement 標(biāo)簽括起來

在子項(xiàng)目中重新指定需要的依賴，刪除范圍和版本號(hào)

5.9 聚合

①：為什么要使用聚合？

將多個(gè)工程拆分為模塊后，需要手動(dòng)逐個(gè)安裝到倉庫后依賴才能夠生效。修改源碼后也需要逐個(gè)手動(dòng)進(jìn)行clean操作。而使用了聚合之后就可以批量進(jìn)行Maven工程的安裝、清理工作。

②：如何配置聚合？

在總的聚合工程中使用moudles/module標(biāo)簽組合，指定模塊工程的相對(duì)路徑即可

6 總結(jié)

maven主要是對(duì)項(xiàng)目的管理和jar包的管理機(jī)制，小伙伴可以到 http://mvnrepository.com/搜索需要的 jar 包的依賴信息。

總結(jié)

以上是生活随笔為你收集整理的谷粒学院（五）---Maven从入门到入魔的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。