POM文件配置解析

    pom.xml：maven項目的核心，定義了項目的基本信息，用於描述項目如何構建，聲明項目的依賴，等等。

    下面一步步解析pom.xml文件的相關配置。

如圖：

• project：是pom.xml的根元素，聲明瞭POM相關的命名空間及xsd元素。

• modelVersion：指定了當前POM的模型版本，對於maven2和maven3來講它只能是4.0.0。

• groupId：定義了項目屬於哪一個組，這個組每每和項目所在的組織或公司相關聯。例如圖中定義理解爲：vinuxpay的mvntest項目。
  

• artifactId：定義了當前maven項目在組中的惟一ID，用來與其餘不一樣的項目或者模塊區別開來。例如圖中是爲HelloWorld項目定義一個artifactId爲hello-world。默認狀況下會以artifactId值開頭生成文件。
  

• version：定義當前項目的版本。SNAPSHOT說明當前項目處於開發中，爲不穩定版本，隨着項目的升級，version會不斷的更新。

• packaging：定義maven項目的打包方式,若是不定義，默認爲jar包。

• name：項目名稱，不是必須的，可是仍是推薦爲每一個POM申明，以方便信息交流。

• description：對項目的描述，不是必須的。

    最重要的groupId、artifactId、version三個元素定義了maven項目的基本座標，任何的jar、pom或者war都是基於這些接本的座標進行區分的。

依賴

依賴配置

如圖：

project > dependencies元素用來配置項目依賴，一個dependencies下能夠配置多個dependency元素用來申明一個或多個項目依賴。

groupId、artifactId、version依賴的基本座標，對於任何一個依賴來講座標是最重要的，Maven根據座標來查找依賴。

type：依賴類型，對應於項目座標定義的packaging。大部分狀況下該屬性沒必要聲明，默認爲jar。

scope：依賴範圍。用來控制依賴與編譯、測試、運行三種classpath的關係。Maven有如下依賴範圍：

1. compile：編譯依賴範圍。若是沒有指定，就默認使用該範圍，對於編譯、測試、運行三種classpath都有效。典型的例子是spring-core,在編譯、測試、運行時都要使用該依賴。

2. test：測試以來範圍，只對測試時有效。例如Junit,只有在編譯和運行測試的時候有效才須要。

3. provided：已提供依賴範圍。只對編譯和測試的classpath有效，運行時無效。例如servlet-API，由於容器已提供，就不須要Maven再引入。

4. runtime：運行時依賴範圍。在測試和運行的classpath有效，編譯時無效。例如JDBC驅動實現，項目主代碼編譯只要提供JDK的JDBC接口，只有在測試和運行時才須要實現上述接口的JDBC驅動。

5. system：系統依賴範圍。依賴關係和provided依賴關係一致。使用時必須經過systemPath顯示的指定以來文件路徑。因爲此依賴不是經過Maven倉庫解析，而是與本機系統綁定，會形成項目移植不可用，需謹慎使用。

6. systemPath也可引用環境變量，如：<systemPath>${JAVA_HOME}/lib/rt.jar</systemPath>
   

7. import(Maven2.0.9以上) ：  導入依賴範圍。    
   

        

optional：可選依賴。用來標記依賴是否可選（true/false）。

exclusions：聲明排除傳遞性依賴。

傳遞性依賴

    最基本理解就是：假設項目A對項目B有一個compile範圍依賴，而項目B對項目C也有一個compile範圍依賴，那麼，C就會成爲A的一個compile範圍依賴。C就是A的一個傳遞性依賴。好處就是：一方面是簡化和方便了依賴申明，另外一方面只需關心項目的直接依賴是什麼，而不用考慮這些直接依賴會引入什麼傳遞性依賴。

可選依賴（optional）

    假設項目A依賴於項目B，項目B依賴於項目X和Y，可是B對於項目X和Y都是可選依賴。若是三者的依賴範圍都是compile，那麼X.Y對於A就是傳遞性依賴，可是因爲X、Y是可選的，那麼對於A來講一來就不會傳遞。例如多數據庫工具包，在構建這個工具包的時候，須要多種數據庫驅動；可是在使用的時候只會依賴一種。

    上圖表示使用optional元素表示mysql-connector-java和postgresql這兩個依賴爲可選依賴，他們只會對B產生影響。當A依賴B項目的時候，這兩個依賴不會被傳遞。當A依賴B的時候，若是使用基於MySQL的數據庫，就須要在A中聲明mysql-connector-java這一依賴。

    最後要說明一點：在理想狀態下是不該該使用可選依賴的，使用可選依賴的緣由就是某一個項目實現了多個特性。基於面向對象的單一性原則，一個類只應該有一項功能，更好的作法是爲mysql-connector-java和postgresql分別建立一個maven項目，基於一樣的groupId分配不一樣的artifactId，根據須要選擇。

排除依賴（exclusions）

    假設項目A依賴項目B，項目B依賴項目C，可是項目C是SNAPSHOT不穩定版本。因爲傳遞性依賴，會照成項目A不穩定，所以須要在依賴B時排除對項目C SNAPSHOT 版本的依賴，而且在項目A中聲明項目C的正式發佈版本。

如圖，代碼中使用了executions聲明排除依賴，能夠包含一個或者多個execution子元素，所以能夠排除一個或多個傳遞性依賴。但要注意的是：聲明execution只須要groupId和artifactId，而不須要version元素。這是由於只要groupId和artifactId就能惟必定位依賴中的某個依賴。換句話說，Maven解析後的依賴中，不可能出現兩個groupId和artifactId都相同，而version不一樣的兩個依賴。

歸類依賴

    有點相似於定義java常量的意思，在一處定義了直接調用就行，而不須要重複定義，或者修改常量值得時候，只需修改一處而不是逐個修改，避免了由於遺漏帶來的沒必要要麻煩。

    如圖，首先使用properties元素定義Maven屬性，而後定義子元素springframework，值爲2.5.6。maven在運行的時候會將POM中的全部${springframework.version}替換成實際值2.5.6。

----------------------------------------------------------------------------------------------------------------

   Maven會自動解析全部項目的直接依賴和傳遞性依賴，而且根據規則正確判斷每一個依賴的範圍，對於一些依賴衝突也能進行調節，確保任何一個構建只有惟一的版本在依賴中存在。

-----------------------------------------------------------------------------------------------------------------

倉庫

    Maven用某一位置存儲全部Maven項目共享構建，這位置就叫倉庫。任何構建都有groupId、artifactId、version這一座標，根據座標能夠肯定其在倉庫存儲的惟一路徑。

路徑與座標的關係大體是：groupId/artifactId/version/artifactId-version.packaging。例如上圖的MVN測試hello-world依賴，在倉庫的路徑就是：vinuxpay.mvntest/vinuxpay.mvntest.hello-world/0.0.1-SNAPSHOT/vinuxpay.mvntest.hello-world-0.0.1-SNAPSHOT.jar。

分類

    分爲兩類：本地倉庫和遠程倉庫。遠程倉庫又包括：中央倉庫（Maven核心自帶）、私服、其餘類型倉庫。如圖：

   構建查找順序： 先查找本地倉庫，若是本地倉庫存在此構建，直接使用。若是不存在，就去遠程倉庫查找，而且下載到本地。若是本地和遠程都沒有，Maven就會報錯。

本地倉庫

    默認路徑： ${user.home}/.m2/repository。

    自定義路徑：修改MAVEN_HOME/config/setting.xml文件的localRepository元素值，如圖：

    對於本地倉庫的依賴，一種是從遠程倉庫中下載至本地倉庫，另外一種是將本地項目的構建經過在該項目路徑下執行mvn clear install安裝。

遠程倉庫

    默認：Maven自帶的核心--中央倉庫。

    配置：在repositories元素下使用repository配置一個或者多個遠程倉庫。

    id：倉庫名稱，必須惟一。不能聲明和Maven自帶中央倉庫的id同樣（central）,不然就會覆蓋掉中央倉庫。

    url：倉庫地址，基於http協議。

    releases和snapshots：用來控制Maven對發佈版和SNAPSHOTS版本構建的下載。若是enabled元素值爲true，表示開啓發布版本的下載支持，但不支持SNAPSHOTS版本的下載支持。

    updatePolicy：表示遠Maven對程倉庫檢查更新的頻率。默認daily，表示天天檢查一次；never：從不檢查更新；always：每次構建都檢查；interval：X--每隔X分鐘檢查一次更新。

    checksumPolicy：用來配置Maven檢查檢驗和文件的策略。當構建被部署到倉庫時，會同時部署對應的校驗和文件。默認爲warn：Maven會在構建時輸出警告信息；fail：Maven會在遇到校驗和錯誤就會讓構建失敗；ignore：徹底忽略校驗和錯誤。

遠程倉庫部署（mvn clean deploy）

    將項目構建部署到遠程倉庫（通常是自建的私服）中POM配置以下：

    repository：發佈版本構建的倉庫。

    snapshotRepository：SNAPSHOT版本的倉庫。

    id：該倉庫的惟一標識。

    對遠程倉庫進行構建部署時候，出於安全方面的考慮，有時咱們要對遠程倉庫的訪問進行認證，通常將認證信息配置在settings.xml中：

    id ：要與POM中repository元素id一致。

    username：認證名。

    password：認證密碼。

   

鏡像

    若是倉庫A可以提供倉庫B的全部內容，那麼A就是B的一個鏡像。例如http://maven.net.cn/content/groups/public就是Maven中央倉庫http://repol.maven.org/maven2在中國的一個鏡像。因爲地理位置因素，該鏡像每每可以比中央倉庫提供更快的服務。所以，能夠配置該鏡像來代替中央倉庫。配置setting.xml以下：

中央倉庫鏡像配置

配置私服鏡像

<mirrorOf>的相關配置：

•     <mirrorOf>*</mirrorOf>：配置全部遠程倉庫

•     <mirrorOf>external:*</mirrorOf>：匹配全部不在本機上的遠程倉庫

•     <mirrorOf>repo1，repo2</mirrorOf>：匹配倉庫repo1和repo2，多個倉庫之間用逗號分隔。

•     <mirrorOf>*，！repo1</mirrorOf>：匹配除repo1之外的全部遠程倉庫。感嘆號表示排除

****************************************************未完，後續更新****************************************