摘要：學(xué)習筆記先生，您在寫代碼嗎不，我們正在完成一項偉大的工程。于是打算重新學(xué)習一下。中央倉庫鏡像為了分擔中央倉庫的流量，提升用戶的訪問速度。生成項目報告，站點，發(fā)布站點。修改源碼后也需要逐個手動進行操作。

先生，您在寫代碼嗎? 不，我們正在完成一項偉大的工程。

在剛學(xué)maven時，我就把maven當作一個引入jar包的工具而已，以前是自己下載jar包，現(xiàn)在是只用在pom文件中填寫相應(yīng)的坐標就可以了。除此之外當我們需要使用的jar包依賴于另一個jar包時，maven會自動幫我們引入適用的版本。這就避免了我們自己下jar包，然后版本不匹配的問題。除此之外，我還模糊的知道一些maven的聚合和繼承，之后在接手項目的時候還是吃了的大虧。于是打算重新學(xué)習一下maven。

Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project"s build, reporting and documentation from a central piece of information.
comprehension: the ability to understand something 理解力
maven是一種軟件項目管理和理解的工具?；陧椖繉ο竽Ｐ偷母拍睢?/p>

但是在后面的what is maven? 我看到這么一句話:

We hope that we have created something that will make the day-to-day work of Java developers easier and generally help with the comprehension of any Java-based project.
我們希望我們編寫的這個工具能夠使得java程序員的工作變得簡單，使得任何使用該工具的任何java工程更加容易理解。

Maven約定了目錄架構(gòu)

如果你在java中放配置文件，很可能會報找不到文件的異常。
但是我就是想在java這個文件夾中放配置文件,該怎么辦呢? 你需要在pom文件中聲明一下

        
            src/main/java
            
                **/*.xml
            
            true
        
    

多數(shù)博客或者視頻都將maven定義為自動化構(gòu)建工具。
那什么是自動化構(gòu)建工具呢？
我們首先來解釋構(gòu)建:

編譯

將java源文件變成字節(jié)碼，交給JVM去執(zhí)行

部署

一個BS項目最終運行的并不是動態(tài)web工程本身，而是這個動態(tài)web工程“編譯的結(jié)果”

構(gòu)建各個過程的步驟:

清理: 將以前編譯得到的舊字節(jié)碼刪除掉

編譯: 將java源代碼變成字節(jié)碼

測試: 執(zhí)行test文件夾中的測試程序

報告: 顯示測試程序執(zhí)行的結(jié)果

打包: 動態(tài)Web工程打成war包，Java工程打成jar包

安裝: Maven的特定概念---將打包得到的文件復(fù)制到"倉庫"中指定的位置

部署: 將動態(tài)Web工程生成的war包復(fù)制到Servlet容器中指定的目錄下,使其可以運行

自動化構(gòu)建,其實上述步驟,在elipse和IDEA中也可以完成,只不過沒那么標準。既然IDE已經(jīng)可以完成這些工作了，那么還要maven干什么呢?
日常開發(fā)中,以下幾個步驟是我們經(jīng)常走的:

編譯

打包

部署

測試

這幾個步驟是程式化的，沒有太大的變數(shù)或者說根本就沒有變數(shù)。程序員們很希望從這些重復(fù)的工作中脫身出來,將這些重復(fù)的工作交給工具去做。此時Maven的意義就體現(xiàn)出來了，它可以自動的從構(gòu)建過程中的起點一直執(zhí)行到終點。

POM

坐標

依賴

倉庫

生命周期/插件/目標

繼承

聚合

POM: a project object model.項目對象模型

對這個概念老實說,我并沒有很深的理解,或者說我并不理解項目對象模型的意思。
有資料說項目對象模型就是將Java工程的相關(guān)信息封裝為對象便于操作和管理的模型。
這個解釋的稍微讓人那么容易那么一點。
學(xué)習Maven就是學(xué)習pom.xml文件中的配置

坐標這個概念我覺得和依賴結(jié)合起來解釋會更好,在沒有Maven之前,我們引入jar包的方式就是先下載，
然后在復(fù)制在類文件路徑下,你的項目需要的jar包，在Maven看來就是你的項目依賴于某些jar包,
pom.xml文件中填寫對應(yīng)jar包的位置，
就可以引入對應(yīng)的jar包

使用如下三個向量在 Maven 的倉庫中唯一的確定一個 Maven 工程。

[1] groupid：公司或組織的域名倒序+當前項目名稱
[2] artifactId：當前項目的模塊名稱
[3] version：當前模塊的版本

    com.atguigu.maven
    Hello
    0.0.1-SNAPSHOT

其實引入對象的依賴非常的簡單，我們只用去Maven的中央倉庫，輸入jar包的名字，選擇你需要的版本，然后將復(fù)制倉庫給出的依賴，粘貼在pom.xml文件中的dependencies標簽下就可以了.
步驟如下:
百度搜索Maven

進入之后

比如說我想要Spring-test的jar包

然后選擇對應(yīng)的版本:

倉庫可以理解為存放jar包的地方。

倉庫的分類

本地倉庫:當前電腦上的部署的倉庫目錄，為當前電腦上的所有Maven工程服務(wù)

遠程倉庫:

  (1) 私服: 搭建在局域網(wǎng)環(huán)境中,為局域網(wǎng)范圍內(nèi)的所有Maven工程服務(wù)
  (2) 中央倉庫: 架設(shè)在Internet上,為全世界范圍內(nèi)所有的Maven工程服務(wù)。
  (3) 中央倉庫鏡像: 為了分擔中央倉庫的流量，提升用戶的訪問速度。

使用properties標簽內(nèi)自定義標簽統(tǒng)一聲明版本號

什么是Maven的生命周期?

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

Maven有三套互相獨立的生命周期:

① Clean Lifecycle 在進行真正的構(gòu)建之前進行一些清理工作
② Default Lifecycle 構(gòu)建的核心部分，編譯，測試，打包，安裝，部署等等。
③ Site Lifecycle 生成項目報告，站點，發(fā)布站點。

它們是相互獨立的，你可以僅僅調(diào)用 clean 來清理工作目錄，僅僅調(diào)用 site 來生成站點。當然你也可以
直接運行 mvn clean install site 運行所有這三套生命周期。
這個生成站點的意思就是: 在本地生成有關(guān)你項目的相關(guān)信息。
長這個樣子:

Clean生命周期:

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

Site生命周期

1 pre-site 執(zhí)行一些需要在生成站點文檔之前完成的工作
2 site 生成項目的站點文檔
3 post-site 執(zhí)行一些需要在生成站點文檔之后完成的工作，并且為部署做準備
4 site-deploy 將生成的站點文檔部署到特定的服務(wù)器上
這里經(jīng)常用到的是 site 階段和 site-deploy 階段，用以生成和發(fā)布 Maven 站點，這可是 Maven相當強大的功能，
Manager比較喜歡，文檔及統(tǒng)計數(shù)據(jù)自動生成，很好看。

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

        validate
        generate-sources
        process-sources
        generate-resources
        process-resources          復(fù)制并處理資源文件，至目標目錄，準備打包。
        compile                    編譯項目的源代碼。
        process-classes
        generate-test-sources   
        process-test-sources
        generate-test-resources
        process-test-resources          復(fù)制并處理資源文件，至目標測試目錄。
        test-compile                    編譯測試源代碼。
        process-test-classes
        test                使用合適的單元測試框架運行測試。這些測試代碼不會被打包或部署。
        prepare-package
        package          接受編譯好的代碼，打包成可發(fā)布的格式，如  JAR  。
        pre-integration-test
        integration-test
        post-integration-test
        verify
        install          將包安裝至本地倉庫，以讓其它項目依賴。
        deploy          將最終的包復(fù)制到遠程的倉庫，以讓其它開發(fā)人員與項目共享
        

maven生命周期（lifecycle）由各個階段組成，每個階段由maven的插件plugin來執(zhí)行完成。

當我們執(zhí)行的maven命令需要用到某些插件時，Maven的核心程序會首先到本地倉庫中查找

本地倉庫的默認位置: 可以在配置文件中指定

我查的資料是

① complie

對主程序是否有效：有效

對測試程序是否有效: 有效

是否參與打包: 參與

是否參與部署: 參與

典型例子: Spring-core

② test

對主程序是否有效: 無效

對測試程序是否有效: 有效

是否參與打包: 不參與

是否參與部署: 不參與

典型例子: junit

③ provided

對主程序是否有效: 有效

對測試程序是否有效: 有效

是否參與打包: 不參與

是否參與部署: 不參與

典型例子: servlet-api.jar

模塊A依賴于模塊B。
模塊B又依賴于C模塊
則模塊A內(nèi)會有C模塊。

讓我們把以上的例子在通俗化一些:

模塊C引入了Spring-corejar包,
那么模塊C中的Maven依賴就會有以下兩個jar包。

模塊A引入模塊B,就會順帶把這兩個jar包一并引入。

模塊A的pom:

但是現(xiàn)在我并不想要commons-logging這個jar包該怎么辦呢?
我們可以排除依賴:

解決jar包沖突
[1] 路徑最短者優(yōu)先

[2] 路徑相同時,先聲明者優(yōu)先

這里指的先聲明者優(yōu)先，是指A、B模塊在A模塊中denpendency標簽配置的先后順序。誰在上面,誰就是先聲明者。

繼承可以幫我們做什么?

統(tǒng)一管理依賴的版本。

一個典型的例子就是:

現(xiàn)在項目下A、B、C三個模塊,三個模塊都依賴著不同的Junit的版本,依賴范圍為test時,依賴又不能傳遞過來,
但是我們希望能夠統(tǒng)一Junit版本,可能有的人自然會想到,
你讓A、B、C模塊pom中的Junit依賴版本寫一致不就行了,這也是個辦法。
但是maven在設(shè)計的時候估計也考慮到了這種情況,就是繼承了。

繼承該如何使用:
①

首先你需要創(chuàng)建一個maven工程,注意指定打包方式為pom    

com.cxkStudy.maven
 Parent
  0.0.1-SNAPSHOT
  學(xué)習Maven使用
  pom
 

②

再創(chuàng)建一個maven工程,在該模塊中指定它的父工程是誰.

 
        com.cxkStudy.maven
          Parent
          0.0.1-SNAPSHOT
    

③

在父項目中確定子模塊的位置
  
    ../studyDenpen
    ../Hello
 

module標簽中填的是相對于父項目的位置。
這也就是聚合了.

為什么要使用聚合?

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

我們可以在父工程里面指定Junit的版本,在子模塊使用Junit的時候不寫版本就好了。

父工程中執(zhí)行Junit的版本:

    
        
        
            junit
            junit
            4.9
            test
        
    

子模塊中引入Junit的時候不指定版本

    
                junit
                junit
   

請注意配置繼承后,執(zhí)行安裝命令要先安裝父工程。

隨著我們的項目越來越大，src下面的包會越來越多,我曾經(jīng)在GitHub下見過一個項目，SRC下面有三十多個包，每個包下面又有很多類。這代碼看的我想吐，不是代碼寫的爛，而是太混雜了，結(jié)構(gòu)不清晰。我們可以將我們的項目根據(jù)功能進行拆分,以避免src下出現(xiàn)太多的包。
比如說，我們可以將某一個模塊專門用來發(fā)布我們寫的功能模塊，某一個模塊放置公共類，某一個模塊存放業(yè)務(wù)代碼。這樣在結(jié)構(gòu)上會更為清晰，但這只用于比較大的工程,小的工程采用如此的拆分還是得不償失。