Maven教程


【更多 Java – Android 資料下載,可訪問尚硅谷(中國)官網 www.atguigu.com  下載區】 
Maven 
 
導言:生產環境下開發不再是一個項目一個工程,而是每一個模塊創建一個工程,而多個模塊整合在一起就需要
使用到像 Maven 這樣的構建工具。 
 
1  Why? 
1.1  真的需要嗎? 
Maven 是幹什麼用的?這是很多同學在剛開始接觸 Maven 時最大的問題。之所以會提出這個問題,
是因爲即使不使用 Maven 我們仍然可以進行 B/S 結構項目的開發。從表述層、業務邏輯層到持久化層
再到數據庫都有成熟的解決方案——不使用 Maven 我們一樣可以開發項目啊? 
 
這裏給大家糾正一個誤區,Maven 並不是直接用來輔助編碼的,它戰鬥的崗位並不是以上各層。所
以我們有必要通過企業開發中的實際需求來看一看哪些方面是我們現有技術的不足。 
 
1.2  究竟爲什麼? 
爲什麼要使用 Maven?它能幫助我們解決什麼問題? 
①添加第三方 jar 包 
在今天的 JavaEE 開發領域,有大量的第三方框架和工具可以供我們使用。要使用這些 jar 包最簡單
的方法就是複製粘貼到 WEB-INF/lib 目錄下。但是這會導致每次創建一個新的工程就需要將 jar 包重複復
制到 lib 目錄下,從而造成工作區中存在大量重複的文件,讓我們的工程顯得很臃腫。 
而使用 Maven 後每個 jar 包本身只在本地倉庫中保存一份,需要 jar 包的工程只需要以座標的方式
簡單的引用一下就可以了。不僅極大的節約了存儲空間,讓項目更輕巧,更避免了重複文件太多而造成
的混亂。 
    ②jar 包之間的依賴關係                                                                         “玩轉”Java 系列 
———————————————————————————————————— 

【更多 Java – Android 資料下載,可訪問尚硅谷(中國)官網 www.atguigu.com  下載區】 
jar 包往往不是孤立存在的,很多 jar 包都需要在其他 jar 包的支持下才能夠正常工作,我們稱之爲
jar 包之間的依賴關係。最典型的例子是:commons-fileupload-1.3.jar 依賴於 commons-io-2.0.1.jar,如果
沒有 IO 包,FileUpload 包就不能正常工作。 
那麼問題來了,你知道你所使用的所有 jar 包的依賴關係嗎?當你拿到一個新的從未使用過的 jar
包,你如何得知他需要哪些 jar 包的支持呢?如果不瞭解這個情況,導入的 jar 包不夠,那麼現有的程
序將不能正常工作。再進一步,當你的項目中需要用到上百個 jar 包時,你還會人爲的,手工的逐一確
認它們依賴的其他 jar 包嗎?這簡直是不可想象的。 
而引入 Maven 後,Maven 就可以替我們自動的將當前 jar 包所依賴的其他所有 jar 包全部導入進來,
無需人工參與,節約了我們大量的時間和精力。用實際例子來說明就是:通過 Maven 導入
commons-fileupload-1.3.jar 後,commons-io-2.0.1.jar 會被自動導入,程序員不必瞭解這個依賴關係。 
下圖是 Spring 所需 jar 包的部分依賴關係 
 
③獲取第三方 jar 包 
JavaEE 開發中需要使用到的 jar 包種類繁多,幾乎每個 jar 包在其本身的官網上的獲取方式都不盡相
同。爲了查找一個 jar 包找遍互聯網,身心俱疲,沒有經歷過的人或許體會不到這種折磨。不僅如此,
費勁心血找的 jar 包裏有的時候並沒有你需要的那個類,又或者又同名的類沒有你要的方法——以不規
範的方式獲取的 jar 包也往往是不規範的。 
使用 Maven 我們可以享受到一個完全統一規範的 jar 包管理體系。你只需要在你的項目中以座標的
方式依賴一個 jar 包,Maven 就會自動從中央倉庫進行下載,並同時下載這個 jar 包所依賴的其他 jar 包                                                                        “玩轉”Java 系列 
———————————————————————————————————— 

【更多 Java – Android 資料下載,可訪問尚硅谷(中國)官網 www.atguigu.com  下載區】 
——規範、完整、準確!一次性解決所有問題! 
Tips:在這裏我們順便說一下,統一的規範幾乎可以說成是程序員的最高信仰。如果沒有統一的規
範,就意味着每個具體的技術都各自爲政,需要以諸多不同的特殊的方式加入到項目中;好不容易加入
進來還會和其他技術格格不入,最終受苦的是我們。而任何一個領域的統一規範都能夠極大的降低程序
員的工作難度,減少工作量。例如:USB 接口可以外接各種設備,如果每個設備都有自己獨特的接口,
那麼不僅製造商需要維護各個接口的設計方案,使用者也需要詳細瞭解每個設備對應的接口,無疑是非
常繁瑣的。 
④將項目拆分成多個工程模塊 
隨着 JavaEE 項目的規模越來越龐大,開發團隊的規模也與日俱增。一個項目上千人的團隊持續開
發很多年對於 JavaEE 項目來說再正常不過。那麼我們想象一下:幾百上千的人開發的項目是同一個 Web
工程。那麼架構師、項目經理該如何劃分項目的模塊、如何分工呢?這麼大的項目已經不可能通過
package 結構來劃分模塊,必須將項目拆分成多個工程協同開發。多個模塊工程中有的是 Java 工程,有
的是 Web 工程。 
那麼工程拆分後又如何進行互相調用和訪問呢?這就需要用到 Maven 的依賴管理機制。大家請看
我們的 Survey 調查項目拆分的情況: 
 
上層模塊依賴下層,所以下層模塊中定義的 API 都可以爲上層所調用和訪問。 
 
2  What? 
2.1  Maven 簡介 
Maven 是 Apache 軟件基金會組織維護的一款自動化構建工具,專注服務於 Java 平臺的項目構建和
依賴管理。Maven 這個單詞的本意是:專家,內行。讀音是['meɪv(ə)n]或['mevn]。 
 
2.2  什麼是構建 
構建並不是創建,創建一個工程並不等於構建一個項目。要了解構建的含義我們應該由淺入深的從
以下三個層面來看:                                                                         “玩轉”Java 系列 
———————————————————————————————————— 

【更多 Java – Android 資料下載,可訪問尚硅谷(中國)官網 www.atguigu.com  下載區】 
①純 Java 代碼 
大家都知道,我們 Java 是一門編譯型語言,.java 擴展名的源文件需要編譯成.class 擴展名的字節碼
文件才能夠執行。所以編寫任何 Java 代碼想要執行的話就必須經過編譯得到對應的.class 文件。 
②Web 工程 
當我們需要通過瀏覽器訪問 Java 程序時就必須將包含 Java 程序的 Web 工程編譯的結果“拿”到服務
器上的指定目錄下,並啓動服務器才行。這個“拿”的過程我們叫部署。 
我們可以將未編譯的 Web 工程比喻爲一隻生的雞,編譯好的 Web 工程是一隻煮熟的雞,編譯部署
的過程就是將雞燉熟。 
Web 工程和其編譯結果的目錄結構對比見下圖: 
 
③實際項目 
在實際項目中整合第三方框架,Web 工程中除了 Java 程序和 JSP 頁面、圖片等靜態資源之外,還
包括第三方框架的 jar 包以及各種各樣的配置文件。所有這些資源都必須按照正確的目錄結構部署到服
務器上,項目纔可以運行。 
所以綜上所述:構建就是以我們編寫的 Java 代碼、框架配置文件、國際化等其他資源文件、JSP 頁
面和圖片等靜態資源作爲“原材料”,去“生產”出一個可以運行的項目的過程。 
那麼項目構建的全過程中都包含哪些環節呢? 
 
2.3  構建過程的幾個主要環節 
①清理:刪除以前的編譯結果,爲重新編譯做好準備。 
②編譯:將 Java 源程序編譯爲字節碼文件。 
③測試:針對項目中的關鍵點進行測試,確保項目在迭代開發過程中關鍵點的正確性。 
④報告:在每一次測試後以標準的格式記錄和展示測試結果。 
⑤打包:將一個包含諸多文件的工程封裝爲一個壓縮文件用於安裝或部署。Java 工程對應 jar 包,Web
工程對應 war 包。 
⑥安裝:在 Maven 環境下特指將打包的結果——jar 包或 war 包安裝到本地倉庫中。 
⑦部署:將打包的結果部署到遠程倉庫或將 war 包部署到服務器上運行。 
2.4  自動化構建 
其實上述環節我們在 Eclipse 中都可以找到對應的操作,只是不太標準。那麼既然 IDE 已經可以進
行構建了我們爲什麼還要使用 Maven 這樣的構建工具呢?我們來看一個小故事:                                                                         “玩轉”Java 系列 
———————————————————————————————————— 

【更多 Java – Android 資料下載,可訪問尚硅谷(中國)官網 www.atguigu.com  下載區】 
這是陽光明媚的一天。托馬斯嚮往常一樣早早的來到了公司,衝好一杯咖啡,進入了自己的郵箱——很
不幸,QA 小組發來了一封郵件,報告了他昨天提交的模塊的測試結果——有 BUG。“好吧,反正也不是第一
次”,托馬斯搖搖頭,進入 IDE,運行自己的程序,編譯、打包、部署到服務器上,然後按照郵件中的操作
路徑進行測試。“嗯,沒錯,這個地方確實有問題”,托馬斯說道。於是托馬斯開始嘗試修復這個 BUG,當他
差不多有眉目的時候已經到了午飯時間。 
下午繼續工作。BUG 很快被修正了,接着托馬斯對模塊重新進行了編譯、打包、部署,測試之後確認沒
有問題了,回覆了 QA 小組的郵件。 
一天就這樣過去了,明媚的陽光化作了美麗的晚霞,托馬斯卻覺得生活並不像晚霞那樣美好啊。 
讓我們來梳理一下托馬斯這一天中的工作內容 
 
從中我們發現,托馬斯的很大一部分時間花在了“編譯、打包、部署、測試”這些程式化的工作上
面,而真正需要由“人”的智慧實現的分析問題和編碼卻只佔了很少一部分。 
 
能否將這些程式化的工作交給機器自動完成呢?——當然可以!這就是自動化構建。 
 
此時 Maven 的意義就體現出來了,它可以自動的從構建過程的起點一直執行到終點: 
 
                                                                         “玩轉”Java 系列 
———————————————————————————————————— 

【更多 Java – Android 資料下載,可訪問尚硅谷(中國)官網 www.atguigu.com  下載區】 
 
2.5  Maven 核心概念 
Maven 能夠實現自動化構建是和它的內部原理分不開的,這裏我們從 Maven 的九個核心概念入手,
看看 Maven 是如何實現自動化構建的 
①POM 
②約定的目錄結構 
③座標 
④依賴管理 
⑤倉庫管理 
⑥生命週期 
⑦插件和目標 
⑧繼承 
⑨聚合 
 
3  How? 
Maven 的核心程序中僅僅定義了抽象的生命週期,而具體的操作則是由 Maven 的插件來完成的。可是
Maven 的插件並不包含在 Maven 的核心程序中,在首次使用時需要聯網下載。 
下載得到的插件會被保存到本地倉庫中。本地倉庫默認的位置是:~\.m2\repository。 
如果不能聯網可以使用我們提供的 RepMaven.zip 解壓得到。具體操作參見“Maven 操作指南.txt”。 
4  約定的目錄結構 
約定的目錄結構對於 Maven 實現自動化構建而言是必不可少的一環,就拿自動編譯來說,Maven 必須
能找到 Java 源文件,下一步才能編譯,而編譯之後也必須有一個準確的位置保持編譯得到的字節碼文件。 
我們在開發中如果需要讓第三方工具或框架知道我們自己創建的資源在哪,那麼基本上就是兩種方式: 
①通過配置的形式明確告訴它 
②基於第三方工具或框架的約定 
Maven 對工程目錄結構的要求就屬於後面的一種。 
 
現在 JavaEE 開發領域普遍認同一個觀點:約定>配置>編碼。意思就是能用配置解決的問題就不編碼,
能基於約定的就不進行配置。而 Maven 正是因爲指定了特定文件保存的目錄才能夠對我們的 Java 工程進行
自動化構建。                                                                         “玩轉”Java 系列 
———————————————————————————————————— 

【更多 Java – Android 資料下載,可訪問尚硅谷(中國)官網 www.atguigu.com  下載區】 
5  POM 
Project Object Model:項目對象模型。將 Java 工程的相關信息封裝爲對象作爲便於操作和管理的模型。
Maven 工程的核心配置。可以說學習 Maven 就是學習 pom.xml 文件中的配置。 
6  座標 
6.1  幾何中的座標 
[1]在一個平面中使用 x、y 兩個向量可以唯一的確定平面中的一個點。 
[2]在空間中使用 x、y、z 三個向量可以唯一的確定空間中的一個點。 
 
6.2  Maven 的座標 
使用如下三個向量在 Maven 的倉庫中唯一的確定一個 Maven 工程。 
[1]groupid:公司或組織的域名倒序+當前項目名稱 
[2]artifactId:當前項目的模塊名稱 
[3]version:當前模塊的版本 
  <groupId>com.atguigu.maven</groupId> 
  <artifactId>Hello</artifactId> 
  <version>0.0.1-SNAPSHOT</version> 
 
6.3  如何通過座標到倉庫中查找 jar 包? 
[1]將 gav 三個向量連起來 
com.atguigu.maven+Hello+0.0.1-SNAPSHOT 
[2]以連起來的字符串作爲目錄結構到倉庫中查找 
com/atguigu/maven/Hello/0.0.1-SNAPSHOT/Hello-0.0.1-SNAPSHOT.jar 
※注意:我們自己的 Maven 工程必須執行安裝操作纔會進入倉庫。安裝的命令是:mvn install 
7  依賴 
Maven 中最關鍵的部分,我們使用 Maven 最主要的就是使用它的依賴管理功能。要理解和掌握 Maven
的依賴管理,我們只需要解決一下幾個問題: 
①依賴的目的是什麼 
當 A jar 包用到了 B jar 包中的某些類時,A 就對 B 產生了依賴,這是概念上的描述。那麼如何在項目
中以依賴的方式引入一個我們需要的 jar 包呢? 
答案非常簡單,就是使用 dependency 標籤指定被依賴 jar 包的座標就可以了。 
<dependency> 
  <groupId>com.atguigu.maven</groupId> 
  <artifactId>Hello</artifactId> 
  <version>0.0.1-SNAPSHOT</version> 
  <scope>compile</scope> 
</dependency> 
 
②依賴的範圍 
大家注意到上面的依賴信息中除了目標 jar 包的座標還有一個 scope 設置,這是依賴的範圍。依賴的範
圍有幾個可選值,我們用得到的是:compile、test、provided 三個。 
[1]從項目結構角度理解 compile 和 test 的區別                                                                         “玩轉”Java 系列 
———————————————————————————————————— 

【更多 Java – Android 資料下載,可訪問尚硅谷(中國)官網 www.atguigu.com  下載區】 
 
結合具體例子:對於 HelloFriend 來說,Hello 就是服務於主程序的,junit 是服務於測試程序的。 
HelloFriend 主程序需要 Hello 是非常明顯的,測試程序由於要調用主程序所以也需要 Hello,所以
compile 範圍依賴對主程序和測試程序都應該有效。 
HelloFriend 的測試程序部分需要 junit 也是非常明顯的,而主程序是不需要的,所以 test 範圍依賴
僅僅對於主程序有效。 
[2]從開發和運行這兩個不同階段理解 compile 和 provided 的區別 
 
[3]有效性總結 
  compile  test  provided 
主程序  √  ×  √ 
測試程序  √  √  √ 
參與部署  √  ×  × 
 
③依賴的傳遞性 
A 依賴 B,B 依賴 C,A 能否使用 C 呢?那要看 B 依賴 C 的範圍是不是 compile,如果是則可用,否則不
可用。 
Maven 工程  依賴範圍  對 A 的可見性 
A  B  C  compile  √ 
D  test  × 
E  provided  × 
 
④依賴的排除 
如果我們在當前工程中引入了一個依賴是 A,而 A 又依賴了 B,那麼 Maven 會自動將 A 依賴的 B 引入當
前工程,但是個別情況下 B 有可能是一個不穩定版,或對當前工程有不良影響。這時我們可以在引入 A 的時
候將 B 排除。 
[1]情景舉例                                                                         “玩轉”Java 系列 
———————————————————————————————————— 

【更多 Java – Android 資料下載,可訪問尚硅谷(中國)官網 www.atguigu.com  下載區】 
 
[2]配置方式 
<dependency> 
     <groupId>com.atguigu.maven</groupId> 
     <artifactId>HelloFriend</artifactId> 
     <version>0.0.1-SNAPSHOT</version> 
     <type>jar</type> 
     <scope>compile</scope> 
     <exclusions> 
          <exclusion> 
              <groupId>commons-logging</groupId> 
              <artifactId>commons-logging</artifactId> 
          </exclusion> 
     </exclusions> 
</dependency> 
[3]排除後的效果 
 
 
⑤統一管理所依賴 jar 包的版本 
對同一個框架的一組 jar 包最好使用相同的版本。爲了方便升級框架,可以將 jar 包的版本信息統一提
取出來 
[1]統一聲明版本號 
<properties> 
     <atguigu.spring.version>4.1.1.RELEASE</atguigu.spring.version> 
</properties> 
其中 atguigu.spring.version 部分是自定義標籤。 
 
[2]引用前面聲明的版本號 
<dependencies> 
     <dependency> 
          <groupId>org.springframework</groupId> 
          <artifactId>spring-core</artifactId> 
          <version>${atguigu.spring.version}</version>                                                                         “玩轉”Java 系列 
———————————————————————————————————— 
10 
【更多 Java – Android 資料下載,可訪問尚硅谷(中國)官網 www.atguigu.com  下載區】 
     </dependency> 
…… 
</dependencies> 
 
[3]其他用法 
<properties> 
     <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> 
</properties> 
 
⑥依賴的原則:解決 jar 包衝突 
[1]路徑最短者優先 
 
[2]路徑相同時先聲明者優先 
       
這裏“聲明”的先後順序指的是 dependency 標籤配置的先後順序。 
 
8  倉庫 
8.1  分類 
[1]本地倉庫:爲當前本機電腦上的所有 Maven 工程服務。 
[2]遠程倉庫 
(1)私服:架設在當前局域網環境下,爲當前局域網範圍內的所有 Maven 工程服務。 
 
(2)中央倉庫:架設在 Internet 上,爲全世界所有 Maven 工程服務。 
(3)中央倉庫的鏡像:架設在各個大洲,爲中央倉庫分擔流量。減輕中央倉庫的壓力,同時更快的                                                                        “玩轉”Java 系列 
———————————————————————————————————— 
11 
【更多 Java – Android 資料下載,可訪問尚硅谷(中國)官網 www.atguigu.com  下載區】 
響應用戶請求。 
8.2  倉庫中的文件 
[1]Maven 的插件 
[2]我們自己開發的項目的模塊 
[3]第三方框架或工具的 jar 包 
※不管是什麼樣的 jar 包,在倉庫中都是按照座標生成目錄結構,所以可以通過統一的方式查詢或依賴。 
 
9  生命週期 
9.1  什麼是 Maven 的生命週期? 
●Maven 生命週期定義了各個構建環節的執行順序,有了這個清單,Maven 就可以自動化的執行構建命
令了。 
 
●Maven 有三套相互獨立的生命週期,分別是:   
①Clean Lifecycle 在進行真正的構建之前進行一些清理工作。 
②Default Lifecycle 構建的核心部分,編譯,測試,打包,安裝,部署等等。 
③Site Lifecycle 生成項目報告,站點,發佈站點。 
它們是相互獨立的,你可以僅僅調用 clean 來清理工作目錄,僅僅調用 site 來生成站點。當然你也可以
直接運行  mvn clean install site  運行所有這三套生命週期。 
 
每套生命週期都由一組階段(Phase)組成,我們平時在命令行輸入的命令總會對應於一個特定的階段。比
如,運行 mvn clean,這個 clean 是 Clean 生命週期的一個階段。有 Clean 生命週期,也有 clean 階段。 
 
9.2  Clean 生命週期 
Clean 生命週期一共包含了三個階段: 
①pre-clean  執行一些需要在 clean 之前完成的工作   
②clean  移除所有上一次構建生成的文件   
③post-clean  執行一些需要在 clean 之後立刻完成的工作   
 
9.3  Site 生命週期 
①pre-site  執行一些需要在生成站點文檔之前完成的工作 
②site  生成項目的站點文檔 
③post-site  執行一些需要在生成站點文檔之後完成的工作,並且爲部署做準備 
④site-deploy  將生成的站點文檔部署到特定的服務器上 
這裏經常用到的是 site 階段和 site-deploy 階段,用以生成和發佈 Maven 站點,這可是 Maven 相當強大
的功能,Manager 比較喜歡,文檔及統計數據自動生成,很好看。 
 
9.4  Default 生命週期 
Default 生命週期是 Maven 生命週期中最重要的一個,絕大部分工作都發生在這個生命週期中。這裏,
只解釋一些比較重要和常用的階段: 
validate 
generate-sources 
process-sources                                                                         “玩轉”Java 系列 
———————————————————————————————————— 
12 
【更多 Java – Android 資料下載,可訪問尚硅谷(中國)官網 www.atguigu.com  下載區】 
generate-resources 
process-resources  複製並處理資源文件,至目標目錄,準備打包。 
compile  編譯項目的源代碼。 
process-classes 
generate-test-sources 
process-test-sources 
generate-test-resources 
process-test-resources  複製並處理資源文件,至目標測試目錄。 
test-compile  編譯測試源代碼。 
process-test-classes 
test  使用合適的單元測試框架運行測試。這些測試代碼不會被打包或部署。 
prepare-package 
package  接受編譯好的代碼,打包成可發佈的格式,如 JAR。 
pre-integration-test 
integration-test 
post-integration-test 
verify 
install 將包安裝至本地倉庫,以讓其它項目依賴。 
deploy 將最終的包複製到遠程的倉庫,以讓其它開發人員與項目共享或部署到服務器上運行。 
 
9.5  生命週期與自動化構建 
運行任何一個階段的時候,它前面的所有階段都會被運行,例如我們運行 mvn  install  的時候,代碼會
被編譯,測試,打包。這就是 Maven 爲什麼能夠自動執行構建過程的各個環節的原因。此外,Maven 的插
件機制是完全依賴 Maven 的生命週期的,因此理解生命週期至關重要。 
10  插件和目標 
●Maven 的核心僅僅定義了抽象的生命週期,具體的任務都是交由插件完成的。 
●每個插件都能實現多個功能,每個功能就是一個插件目標。 
●Maven 的生命週期與插件目標相互綁定,以完成某個具體的構建任務。 
例如:compile 就是插件 maven-compiler-plugin 的一個目標;pre-clean 是插件 maven-clean-plugin 的一個目標。 
11  繼承 
11.1 爲什麼需要繼承機制? 
由於非 compile 範圍的依賴信息是不能在“依賴鏈”中傳遞的,所以有需要的工程只能單獨配置。例如: 
Hello  <dependency> 
  <groupId>junit</groupId> 
  <artifactId>junit</artifactId> 
  <version>4.0</version> 
  <scope>test</scope> 
</dependency> 
HelloFriend  <dependency> 
  <groupId>junit</groupId> 
  <artifactId>junit</artifactId> 
  <version>4.0</version>                                                                         “玩轉”Java 系列 
———————————————————————————————————— 
13 
【更多 Java – Android 資料下載,可訪問尚硅谷(中國)官網 www.atguigu.com  下載區】 
  <scope>test</scope> 
</dependency> 
MakeFriend  <dependency> 
  <groupId>junit</groupId> 
  <artifactId>junit</artifactId> 
  <version>4.0</version> 
  <scope>test</scope> 
</dependency> 
此時如果項目需要將各個模塊的 junit 版本統一爲 4.9,那麼到各個工程中手動修改無疑是非常不可取的。
使用繼承機制就可以將這樣的依賴信息統一提取到父工程模塊中進行統一管理。 
 
11.2 創建父工程 
創建父工程和創建一般的 Java 工程操作一致,唯一需要注意的是:打包方式處要設置爲 pom。 
 
11.3 在子工程中引用父工程 
<parent> 
  <!--  父工程座標  --> 
<groupId>...</groupId> 
  <artifactId>...</artifactId> 
  <version>...</version> 
  <relativePath>從當前目錄到父項目的 pom.xml 文件的相對路徑</relativePath> 
</parent> 
<parent> 
  <groupId>com.atguigu.maven</groupId> 
  <artifactId>Parent</artifactId> 
  <version>0.0.1-SNAPSHOT</version> 
   
  <!-- 指定從當前子工程的pom.xml文件出發,查找父工程的pom.xml的路徑 --> 
  <relativePath>../Parent/pom.xml</relativePath> 
</parent> 
 
此時如果子工程的 groupId 和 version 如果和父工程重複則可以刪除。 
 
11.4 在父工程中管理依賴 
將 Parent 項目中的 dependencies 標籤,用 dependencyManagement 標籤括起來 
<dependencyManagement> 
  <dependencies> 
    <dependency> 
      <groupId>junit</groupId> 
      <artifactId>junit</artifactId> 
      <version>4.9</version> 
      <scope>test</scope>                                                                         “玩轉”Java 系列 
———————————————————————————————————— 
14 
【更多 Java – Android 資料下載,可訪問尚硅谷(中國)官網 www.atguigu.com  下載區】 
    </dependency> 
  </dependencies> 
</dependencyManagement> 
在子項目中重新指定需要的依賴,刪除範圍和版本號 
<dependencies> 
  <dependency> 
    <groupId>junit</groupId> 
    <artifactId>junit</artifactId> 
  </dependency> 
</dependencies> 
 
12  聚合 
12.1 爲什麼要使用聚合? 
將多個工程拆分爲模塊後,需要手動逐個安裝到倉庫後依賴才能夠生效。修改源碼後也需要逐個手動進
行 clean 操作。而使用了聚合之後就可以批量進行 Maven 工程的安裝、清理工作。 
 
12.2 如何配置聚合? 
在總的聚合工程中使用 modules/module 標籤組合,指定模塊工程的相對路徑即可 
<modules> 
  <module>../Hello</module> 
  <module>../HelloFriend</module> 
  <module>../MakeFriends</module> 
</modules> 
 
13  Maven 酷站 
我們可以到 http://mvnrepository.com/搜索需要的 jar 包的依賴信息。 
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章