maven - 聚合/繼承 以及Scope的分類

maven - 聚合/繼承 以及Scope的分類

聚合

簡單的方式來編譯項目，jar和插件版本統一管理

依賴管理

利用<dependencyManagement>元素，可被繼承。dependencyManagement的特性：在dependencyManagement中配置的元素既不會給parent引入依賴，也不會給它的子模塊引入依賴，僅僅是它的配置是可繼承的。
parent中定義

<dependencyManagement>  
   <dependencies>  
      <dependency>  
         <groupId>your groupId</groupId>  
         <artifactId>yourartifactId</artifactId>
         <version>${target.version}</version>  
      </dependency>  
   </dependencies>  
 </dependencyManagement>

子項目中添加依賴不須要指定版本

<dependencies>  
      <dependency>  
         <groupId>your groupId</groupId>  
         <artifactId>yourartifactId</artifactId>
      </dependency>  
   </dependencies>

插件管理

利用<pluginManagement>元素，配置方式同上

注意如下幾點：

1. 該aggregator自己也作爲一個Maven項目，它必須有本身的POM
2. 它的打包方式必須爲： pom
3. 引入了新的元素：modules---module
4. 版本：聚合模塊的版本和被聚合模塊版本一致
5. relative path：每一個module的值都是一個當前POM的相對目錄
6. 目錄名稱：爲了方便的快速定位內容，模塊所處的目錄應當與其artifactId一致(Maven約定而不是硬性要求)，總之，模塊所處的目錄必須和<module>模塊所處的目錄</module>相一致。
7. 習慣約定：爲了方便構建，一般將聚合模塊放在項目目錄層的最頂層，其它聚合模塊做爲子目錄存在。這樣當咱們打開項目的時候，第一個看到的就是聚合模塊的POM
8. 聚合模塊減小的內容：聚合模塊的內容僅僅是一個pom.xml文件，它不包含src/main/java、src/test/java等目錄，由於它只是用來幫助其它模塊構建的工具，自己並無實質的內容。
9. 聚合模塊和子模塊的目錄：他們能夠是父子類，也能夠是平行結構，固然若是使用平行結構，那麼聚合模塊的POM也須要作出相應的更改。

繼承

作面向對象編程的人都會以爲這是一個沒意義的問題，是的，繼承就是避免重複，maven的繼承也是這樣，它還有一個好處就是讓項目更加安全

情景分析二：咱們在項目開發的過程當中，可能多個模塊獨立開發，可是多個模塊可能依賴相同的元素，好比說每一個模塊都須要Junit，使用spring的時候，其核心jar也必須都被引入，在編譯的時候，maven-compiler-plugin插件也要被引入

如何配置繼承：

1. 到繼承確定是一個父子結構，那麼咱們在aggregator中來建立一個parent project
2. <packaging>: 做爲父模塊的POM，其打包類型也必須爲POM
3. 結構：父模塊只是爲了幫助咱們消除重複，因此它也不須要src/main/java、src/test/java等目錄
4. 新的元素：<parent> ， 它是被用在子模塊中的
5. <parent>元素的屬性：<relativePath>: 表示父模塊POM的相對路徑，在構建的時候，Maven會先根據relativePath檢查父POM，若是找不到，再從本地倉庫查找
6. relativePath的默認值： ../pom.xml
7. 子模塊省略groupId和version： 使用了繼承的子模塊中能夠不聲明groupId和version, 子模塊將隱式的繼承父模塊的這兩個元素

可被繼承的POM元素

groupId:項目組ID,項目座標的核心元素
version: 項目版本, 項目座標的核心元素
description: 項目的描述信息
organization: 項目的組織信息
inceptionYear: 項目的創始年份
url: 項目的URL地址
developers: 項目開發者信息
contributors: 項目的貢獻者信息
distributionManagement: 項目的部署配置
issueManagement: 項目的缺陷跟蹤系統信息
ciManagement: 項目的持續集成系統信息
scm: 項目的版本控制系統信息
mailingLists: 項目的郵件列表信息
properties: 自定義的maven屬性
dependencies: 項目的依賴配置
dependencyManagement: 項目的依賴管理配置
repositories: 項目的倉庫配置
build: 包括項目的源碼目錄配置、輸出目錄配置、插件配置、插件管理配置等
reporting: 包括項目的報告輸出目錄配置、報告插件配置等

DependencyManagement應用場景

當咱們的項目模塊不少的時候，咱們使用Maven管理項目很是方便，幫助咱們管理構建、文檔、報告、依賴、scms、發佈、分發的方法。能夠方便的編譯代碼、進行依賴管理、管理二進制庫等等。

因爲咱們的模塊不少，因此咱們又抽象了一層，抽出一個itoo-base-parent來管理子項目的公共的依賴。爲了項目的正確運行，必須讓全部的子項目使用依賴項的統一版本，必須確保應用的各個項目的依賴項和版本一致，才能保證測試的和發佈的是相同的結果。

在咱們項目頂層的POM文件中，咱們會看到dependencyManagement元素。經過它元素來管理jar包的版本，讓子項目中引用一個依賴而不用顯示的列出版本號。Maven會沿着父子層次向上走，直到找到一個擁有dependencyManagement元素的項目，而後它就會使用在這個dependencyManagement元素中指定的版本號。

這樣作的好處：統一管理項目的版本號，確保應用的各個項目的依賴和版本一致，才能保證測試的和發佈的是相同的成果，所以，在頂層pom中定義共同的依賴關係。同時能夠避免在每一個使用的子項目中都聲明一個版本號，這樣想升級或者切換到另外一個版本時，只須要在父類容器裏更新，不須要任何一個子項目的修改；若是某個子項目須要另一個版本號時，只須要在dependencies中聲明一個版本號便可。子類就會使用子類聲明的版本號，不繼承於父類版本號。

scope的分類

compile

默認就是compile，什麼都不配置也就是意味着compile。compile表示被依賴項目須要參與當前項目的編譯，固然後續的測試，運行週期也參與其中，是一個比較強的依賴。打包的時候一般須要包含進去。

test

scope爲test表示依賴項目僅僅參與測試相關的工做，包括測試代碼的編譯，執行。比較典型的如junit。

runntime

runntime表示被依賴項目無需參與項目的編譯，不事後期的測試和運行週期須要其參與。與compile相比，跳過編譯而已，說實話在終端的項目（非開源，企業內部系統）中，和compile區別不是很大。比較常見的如JSR×××的實現，對應的API jar是compile的，具體實現是runtime的，compile只須要知道接口就足夠了。oracle jdbc驅動架包就是一個很好的例子，通常scope爲runntime。另外runntime的依賴一般和optional搭配使用，optional爲true。我能夠用A實現，也能夠用B實現。

provided

provided意味着打包的時候能夠不用包進去，別的設施(Web Container)會提供。事實上該依賴理論上能夠參與編譯，測試，運行等週期。至關於compile，可是在打包階段作了exclude的動做。

system

從參與度來講，也provided相同，不過被依賴項不會從maven倉庫抓，而是從本地文件系統拿，必定須要配合systemPath屬性使用。