摘要：的主要思想是約定優于配置。強烈建議遵循以上規范，避免不必要的麻煩。依賴傳遞依賴范圍除了控制，還會對依賴傳遞產生影響。此外還提供了和來進一步管理依賴，分別稱為可選依賴和排除依賴。

Maven 是跨平臺的項目管理工具，主要服務于基于Java平臺的項目構建、依賴管理和項目信息管理。Maven 的主要思想是約定優于配置。通過將約定項目的目錄結構，抽象項目的生命周期的方式，將程序員從繁瑣的項目構建中解放出來。

注：本文用的是 maven-3.5.0 版本。

日常工作除了編寫源代碼，每天有相當一部分時間花在了項目構建中，他們包括項目的編譯、運行單元測試、生成文檔、打包和部署等煩瑣且不起眼的工作。

項目自動化構建。Maven 提供一套規范以及一系列腳本，從清理、編譯、測試到生成報告，再到打包和部署實現自動化構建。還提供了插件擴展的方式，進一步簡化構建的過程。Maven 還能對項目進行編譯、測試、打包，并且將項目生成的構建部署到倉庫中。

Maven 是跨平臺的。對外提供了一致的操作接口，無論在 windows 平臺、Linux 平臺還是 Mac 上都能用相同的命令進行操作。同時，Maven 項目目錄結構、測試用例命名方式等內容都有既定的規則，只要遵循了這些成熟的規則，用戶在項目間切換的時候就免去了額外的學習成本。

Maven 是依賴管理工具。Java 項目需要依賴許多的 jar 包，隨著依賴的增多，版本不一致、版本沖突、依賴臃腫等問題都會接踵而來。Maven 通過倉庫統一存儲這些 jar 包，并通過 pom 文件來管理這些依賴。

Maven 是項目配置工具。Maven能幫助我們管理原本分散在項目中各個角落的項目信息，包括項目描述、開發者列表、版本控制系統地址、許可證、缺陷管理系統地址等。

以上是 Maven 的概念模型，前面說過 Maven 能管理眾多的 jar 包，并且梳理他們之間的依賴關系。Maven 通過 pom 文件和倉庫進行實現。

如果沒有 maven 我們要使用一個 jar 包要從項目的官網尋找下載 jar 到本地，然后再將 jar 包導入到項目中。這樣存在幾個問題：

去相應的網站尋找 jar 包費精力

下載之后當需要用到某一個 jar 包的時候還要在本地找 jar 包

依賴的 jar 包有多個版本要怎么管理

...

最好的解決方式就是將這些 jar 包統一管理，每次只要去一個地方找就可以了。

Maven 就幫我們做了這樣一件事情，他提供一個免費的中央倉庫http://repo1.maven.org/maven2,該中央倉庫包含了世界上大部分流行的開源項目。

我們可以從中央倉庫下載需要的 jar 包，從中央倉庫下載的 jar 包會統一保存在 maven 的本地倉庫中。本地倉庫在本機的.m2文件夾中。

本地倉庫更多相關信息可以去搜索 maven 的安裝教程。

遠程倉庫除了中央倉庫還有私服和其他公共倉庫。

私服是一種特殊的遠程倉庫，它是架設在局域網內的倉庫服務，私服代理廣域網上的遠程倉庫，供局域網內的Maven用戶使用。

上圖是搭建私服的示意圖。私服會將其他公共倉庫的 jar 緩存到搭建的服務器上，局域網內的用戶還可以將構建的項目直接放到私服上供其他開發人員使用。

架設私服是 Maven 推薦的做法，私服減少中央服務器的壓力。如果沒有私服，每次請求都需要向中央服務器請求，有了私服之后通過私服的服務器向中央倉庫請求，局域網內的用戶只需要向私服請求即可。

比如 Maven 的中央倉庫部署在國外，國內訪問外網速度不夠，我們可以在國內架設 Maven 的公共倉庫。

如果倉庫 X 可以提供倉庫 Y 存儲的所有內容，那么就可以認為 X 是 Y 的一個鏡像，顯然在國內我們需要一個中央倉庫的鏡像。http://maven.net.cn/content/groups/public/是中央倉庫，http://repo1.maven.org/maven2/在中國的鏡像。

Maven 默認是從中央倉庫下載文件的，想要讓其從其他地方下載文件就要進行配置，這里就需要操作 maven 的 setting.xml 文件了。

在安裝好 maven 的基礎上，進入 maven 的安裝目錄，可以看到如下的目錄結構：

bin : mvn 的一些腳本文件

boot : 含有 plexus-classworlds 類加載器框架

conf : 配置文件

lib : maven 所使用的 jar 包（maven 基于 java 開發）

setting.xml 文件就在conf目錄中。這里的setting.xml是 maven 全局的配置文件，不建議修改。修改之后會影響 maven 的升級等操作。常用的做法是拷貝一份setting.xml到 maven 本地倉庫的同一目錄下，而本地倉庫配置在用戶目錄的.m2文件夾中，此時的setting.xml就是用戶級別的配置文件。

強烈建議遵循以上規范，避免不必要的麻煩。

接下來就來看setting.xml的一些配置了。

首先localRepository定義本地倉庫位置，默認在用戶目錄下的.m2/repository中。

Default: ${user.home}/.m2/repository


    /path/to/local/repo

前面講過有中央倉庫和其他遠程倉庫，配置遠程倉庫就在repositories中配置。

        
             jboss
             JBoss Repository
            http://repository.jboss.com/maven2/
            
                true
               daily
            
            
                 false
                 warn
           
             default
      

在repositories元素下，可以使用repository子 元素聲明一個或者多個遠程倉庫。

＜settings＞ …… 
＜mirrors＞ 
＜mirror＞ 
＜id＞maven.net.cn＜/id＞ 
＜name＞one of the central mirrors in China ＜/name＞
＜url＞ http://maven.net.cn/content/groups/public/ ＜/url＞ 
＜mirrorOf＞central＜/mirrorOf＞ ＜/mirror＞ ＜/mirrors＞ …… 
＜/settings＞

     
       maven.oschina.net
       maven mirror in China
      http://maven.oschina.net/content/groups/public/
       central
    

以下網站提供 Maven 倉庫搜索功能。

Sonatype Nexus地址：http://repository.sonatype.org/

MVNrepository地址：http://mvnrepository.com/

一般我就用最后一個搜索。

現在有了倉庫統一保管這些 jar 包，剩下的問題就是怎么取了。

不知道你有沒有取快遞的經驗。我們可以這些 jar 包想象成是快遞，倉庫中保管著這些快遞。我們去認領快遞需要依靠快遞單來確定，一張快遞單上會有單號、我們的姓名、手機號等信息。依靠這些信息就不會領錯快遞了。

這里的快遞單就像 Maven 中的 pom 文件，單子上的信息就像是 pom 文件中的坐標系。

Maven 項目規定的項目結構是這樣的：

src/main/java —— 存放項目的.java文件

src/main/resources —— 存放項目資源文件，如spring, hibernate配置文件

src/test/java —— 存放所有測試.java文件，如JUnit測試類

src/test/resources —— 測試資源文件

target —— 項目輸出位置

pom.xml——maven項目核心配置文件

每個 maven 項目都有 pom.xml 文件。Maven坐標為各種構件引入了秩序，任何一個構件都必須明確定義自己的坐標。

一組 Maven坐標是通過一些元素定義的，它們是 groupId、artifactId、version、packaging、 classifier：

groupId：定義當前Maven項目隸屬的實際項目，通常為域名反寫

artifactId：該元素定義實際項目中的一個 Maven項目（模塊），推薦的做法是使用實際項目名稱作為artifactId的前綴。

version：該元素定義Maven項目當前所處的 版本，

packaging：該元素定義Maven項目的打包方 式。當不定義packaging的時候，Maven會使用默認值jar。

classifier：該元素用來幫助定義構建輸出的一些附屬構件。

通過坐標系我們來保證項目在 Maven 倉庫中的唯一性，每次取也不會取錯了。

我們自己項目需要用別人的 jar 包，比如 spring。這就是我們的項目依賴于 spring，因此我們通過 pom 來配置這樣的依賴關系，這樣就能讓項目有清晰的結構。

依賴的關系用用標簽來表示依賴：

上圖說明該項目依賴了 hibernate 等

現在來考慮一種情況，我們在項目開發的過程中用到了 junit 進行測試，也就是說我們的項目依賴于 junit。在項目構建的過程中我們會把 junit 也打包在項目中。但是在生產環境中完全沒有必要用到 junit，我們并不想將它發布到生產環境中。

我們可以每次在發布項目之前把他刪除了對么？那如果依賴 servlet-api，我們只有在編譯和測試項目的時候需要該依賴，但在運行項目的時候，由于容器已經提供，也不需要 Maven 重復地引入一遍。

所以最好是在編譯、測試、運行的過程中需要用到什么 jar 包，就讓 Maven 去打包什么。

maven 為此提供了scope標簽表示依賴范圍，表示該 jar 包在什么時候需要被使用。

compile：編譯依賴范圍，使用此依賴范圍對于編譯、測試、運行三種classpath都有效，即在編譯、測試和運行時都要使用該依賴jar包；

test：測試依賴范圍，只對測試有效，表明只在測試的時候需要，在編譯和運行時將無法使用該類依賴，如 junit；

provided：已提供依賴范圍。編譯和測試有效，運行無效。如servlet-api，在項目運行時，tomcat等容器已經提供，無需Maven重復引入；

runtime：運行時依賴范圍。測試和運行有效，編譯無效。如 jdbc 驅動實現，編譯時只需接口，測試或運行時才需要具體的 jdbc 驅動實現；

system：系統依賴范圍，使用system范圍的依賴時必須通過systemPath元素顯示地指定依賴文件的路徑，不依賴Maven倉庫解析，所以可能會造成建構的不可移植，謹慎使用。

依賴范圍除了控制classpath，還會對依賴傳遞產生影響。如果A依賴B，B依賴C，則A對于B是第一直接依賴。B對于C是第二直接依賴。A對于C是傳遞性依賴。結論是：第一直接依賴的范圍和第二直接依賴的范圍決定了傳遞性依賴的范圍。

第一列是第一直接依賴，第一行是第二直接依賴，中間表示傳遞性依賴范圍。

此外 maven 還提供了option和exclusions來進一步管理依賴，分別稱為可選依賴和排除依賴。

在依賴中添加 true/false 表示是否向下傳遞。

如上圖所示，B 依賴于 X,Y 而 A 依賴于 B，如果 B 不希望將依賴傳遞給 A 則可以配置 B 中的 X,Y 依賴的optional為 true 來阻止依賴的傳遞。

再來看一種情況，A 依賴于 B，且 B 將他的依賴 C 傳遞給了 A。但是 A 依賴了 C 的另一個版本。這個時候 A 可以主動排除 B 給的 C 依賴，轉而使用自己需要的版本，這就用到了exclusions標簽。

用exclusions元素聲明排除依賴，exclusions可以包 含一個或者多個exclusion子元素，因此可以排除一個或者多個傳遞性依賴。

所以我用主動和被動的方式來區分他們。

接上面的問題，如果 A 和 B 依賴 C 的不同版本，而且既沒有配置可選依賴也沒有配置排除依賴。兩個版本都被解析顯然是不對的，因為那會造成依賴重復，因此必須選擇一個。

路徑最近者優先。如果直接與間接依賴中包含有同一個坐標不同版本的資源依賴，以直接依賴的版本為準。

第一聲明者優先。在依賴路徑長度相等的前 提下，在POM中依賴聲明的順序決定了誰會被解析使用，順序最靠前的那個依賴優勝。

上面例子中,A -> C(1.10) 和 A -> B -> C(?),C(1.10)的路徑短所以用它。

Maven的生命周期就是為了對所有的構建過程進行抽象和統一。這個生命周期包含了項目的 清理、初始化、編譯、測試、打包、集成測試、 驗證、部署和站點生成等幾乎所有構建步驟。

初學者往往會以為Maven的生命周期是一個整體，其實不然。Maven擁有三套相互獨立的生命周期，它們分別為clean、default和site。clean生命周期的目的是清理項目，default生命周期的目的是構建項目，而site生命周期的目的是建立項目站點。

clean生命周期的目的是清理項目，它包含三個階段：

pre-clean 執行一些需要在clean之前完成的工作

clean 移除所有上一次構建生成的文件

post-clean 執行一些需要在clean之后立刻完成的工作

mvn clean 中的clean就是上面的clean，在一個生命周期中，運行某個階段的時候，它之前的所有階段都會被運行，也就是說，mvn clean 等同于 mvn pre-clean clean ，如果我們運行 mvn post-clean ，那么 pre-clean，clean 都會被運行。這是Maven很重要的一個規則，可以大大簡化命令行的輸入。

default生命周期定義了真正構建時所需要執 行的所有步驟，它是所有生命周期中最核心的部分，其包含的階段如下：

validate

generate-sources

process-sources

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 將最終的包復制到遠程的倉庫，以讓其它開發人員與項目共享。

運行任何一個階段的時候，它前面的所有階段都會被運行，這也就是為什么我們運行mvn install 的時候，代碼會被編譯，測試，打包。此外，Maven的插件機制是完全依賴Maven的生命周期的，因此理解生命周期至關重要。

site生命周期的目的是建立和發布項目站點，Maven能夠基于POM所包含的信息，自動生成一個友好的站點，方便團隊交流和發布項目信息。

pre-site 執行一些需要在生成站點文檔之前完成的工作

site 生成項目的站點文檔

post-site 執行一些需要在生成站點文檔之后完成的工作，并且為部署做準備

site-deploy 將生成的站點文檔部署到特定的服務器上

這里經常用到的是site階段和site-deploy階段，用以生成和發布Maven站點，這可是Maven相當強大的功能，Manager比較喜歡，文檔及統計數據自動生成，很好看。

mvn clean：該命令調用clean生命周期的clean階段。實際執行的階段為clean生命周期的 pre-clean和clean階段。

mvn test：該命令調用default生命周期的test階段。實際執行的階段為default生命周期的 validate、initialize等，直到test的所有階段。這也解釋了為什么在執行測試的時候，項目的代碼能夠自動得以編譯。

mvn clean install：該命令調用clean生命周期 的clean階段和default生命周期的install階段。

mvn clean deploy site-deploy：該命令調用 clean生命周期的clean階段、default生命周期的 deploy階段，以及site生命周期的site-deploy階段。

軟件設計人員往往會采用各種方式對軟件劃分模塊，以得到更清晰的設計及更高的重用性。當把Maven應用到實際項目中的時候，也需要將項目分成不同的模塊。

簡單的說就是有 A,B 兩個模塊，現在想要將他們統一管理。Maven 的聚合特性能夠把項目的各個模塊聚合在一起構建，而Maven的繼承特性則能幫助抽取各模塊相同的依賴和插件等配置，在簡化POM的同時，還能促進各個模塊配置的一致性。

兩個子模塊希望同時構建。這時，一個簡單的需求就會自然而然地顯現出來：我們會想要一次構建兩個項目，而不是到兩個模塊的目錄下分別執行mvn命令。Maven聚合（或者稱為多模塊）這一特性就是為該需求服務的。

上圖所示api是一個模塊，cmd是一個模塊他們都有各自的 pom 文件，其實每一個包都是一個子模塊，而最底下的 pom 文件則是統一管理這些子模塊。

他們的配置很簡單，我們最好遵循規范。

api 的 pom.xml

    
        com.shuiyujie.fu
        sop
        1.0-SNAPSHOT
    

    4.0.0
    api
    ...

cmd 的 pom.xml

    
        com.shuiyujie.fu
        sop
        1.0-SNAPSHOT
    

    4.0.0
    cmd

聚合 pom.xml

    4.0.0
    com.shuiyujie.fu
    pom
    sop
    1.0-SNAPSHOT
    sop
    http://maven.apache.org
    ...    
        
        base
        core
        server
        persist
        api
        impl
        cmd
    
    ...

觀察上面的三個代碼清單可以聚合 pom 文件中定義了 標簽，標簽中包含的就是各個子模塊，并且用子模塊的artifactId來標記他們。

注意：聚合 pom 文件的打包方式，即 packaging 必須為 pom。

這樣只需要構建聚合 pom 文件即可同時構建在其管理下的多個子模塊。

消除重復。在面向對象世界中，程序員可以使用類繼承在一定程度上消除重復，在Maven的世界 中，也有類似的機制能讓我們抽取出重復的配 置，這就是POM的繼承。

任然看上面的三個 pom.xml 代碼清單，子模塊都有一個parent標簽，這就表明他們繼承了一個 pom 文件，而parent標簽下的其他標簽就是一個坐標系，通過一個坐標系就能定位一個唯一的項目。

比如上面的子模塊繼承自聚合 pom 文件，所以此時聚合 pom 文件也是父類 pom 文件。

在繼承的過程中我們考慮一種情形，我們希望在父類中統一控制 spring 的版本，然后子類繼承自父類就可以使用統一版本的 spring 依賴了。但是有些子模塊不需要依賴 spring，并不需要從父類繼承 spring 的依賴。

我們可以使用dependencyManagement 標簽。

父類 pom.xml

        
            
            
                ${project.groupId}
                core
                ${project.version}
            
            
                ${project.groupId}
                persist
                ${project.version}
            
            
                ${project.groupId}
                api
                ${project.version}
            
            
                ${project.groupId}
                impl
                ${project.version}
            
            
                ${project.groupId}
                server
                ${project.version}
            
            
                ${project.groupId}
                cmd
                ${project.version}
            
            
        
    

父類dependencyManagement中聲明了各個子模塊，子模塊之間有的會需要相互引用，有的卻并不需要。所以在父類中統一配置各個子模塊的groupId,artifactId,version等基本信息。

在dependencyManagement中聲明的依賴不會在當前pom中引入依賴，也不會再繼承他的pom中引入依賴，他的作用只是聲明了可能要引入依賴的一些通用信息。

如果要使用一個子模塊要使用其他子模塊就可以另外聲明，但是不需要指定版本等通用信息，這樣就可以減少依賴沖突的發生，代碼如下：

    
        com.shuiyujie.fu
        sop
        1.0-SNAPSHOT
    

    4.0.0
    api

    
        
            ${project.parent.groupId}
            fu-persist
        
    

Maven 的核心思想是約定優于配置。

首先，Maven 約定了項目的結構，我們不需要配置 Maven 編譯、打包等操作時文件的位置。統一的項目結構降低了學習的成本，讓我能將精力集中到了項目本身。

其次，Maven 抽象了項目構建的過程，將其分成一個個生命周期進行管理。通過命令和插件的形式進一步簡化操作，又讓我們從繁瑣的操作解放出來。

《Maven 實戰》

Maven遠程倉庫的各種配置

本文大部分內容來自于《Maven 實戰》一書，想要了解一手信息強烈建議閱讀。網上的其他文章基本上都是摘抄《Maven 實戰》的部分內容。
所以還想說一遍：發現一本好書就像發現了一座寶藏。