摘要：的主要思想是約定優(yōu)于配置。強(qiáng)烈建議遵循以上規(guī)范，避免不必要的麻煩。依賴傳遞依賴范圍除了控制，還會(huì)對(duì)依賴傳遞產(chǎn)生影響。此外還提供了和來進(jìn)一步管理依賴，分別稱為可選依賴和排除依賴。

Maven 是跨平臺(tái)的項(xiàng)目管理工具，主要服務(wù)于基于Java平臺(tái)的項(xiàng)目構(gòu)建、依賴管理和項(xiàng)目信息管理。Maven 的主要思想是約定優(yōu)于配置。通過將約定項(xiàng)目的目錄結(jié)構(gòu)，抽象項(xiàng)目的生命周期的方式，將程序員從繁瑣的項(xiàng)目構(gòu)建中解放出來。

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

日常工作除了編寫源代碼，每天有相當(dāng)一部分時(shí)間花在了項(xiàng)目構(gòu)建中，他們包括項(xiàng)目的編譯、運(yùn)行單元測(cè)試、生成文檔、打包和部署等煩瑣且不起眼的工作。

項(xiàng)目自動(dòng)化構(gòu)建。Maven 提供一套規(guī)范以及一系列腳本，從清理、編譯、測(cè)試到生成報(bào)告，再到打包和部署實(shí)現(xiàn)自動(dòng)化構(gòu)建。還提供了插件擴(kuò)展的方式，進(jìn)一步簡(jiǎn)化構(gòu)建的過程。Maven 還能對(duì)項(xiàng)目進(jìn)行編譯、測(cè)試、打包，并且將項(xiàng)目生成的構(gòu)建部署到倉庫中。

Maven 是跨平臺(tái)的。對(duì)外提供了一致的操作接口，無論在 windows 平臺(tái)、Linux 平臺(tái)還是 Mac 上都能用相同的命令進(jìn)行操作。同時(shí)，Maven 項(xiàng)目目錄結(jié)構(gòu)、測(cè)試用例命名方式等內(nèi)容都有既定的規(guī)則，只要遵循了這些成熟的規(guī)則，用戶在項(xiàng)目間切換的時(shí)候就免去了額外的學(xué)習(xí)成本。

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

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

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

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

去相應(yīng)的網(wǎng)站尋找 jar 包費(fèi)精力

下載之后當(dāng)需要用到某一個(gè) jar 包的時(shí)候還要在本地找 jar 包

依賴的 jar 包有多個(gè)版本要怎么管理

...

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

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

我們可以從中央倉庫下載需要的 jar 包，從中央倉庫下載的 jar 包會(huì)統(tǒng)一保存在 maven 的本地倉庫中。本地倉庫在本機(jī)的.m2文件夾中。

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

遠(yuǎn)程倉庫除了中央倉庫還有私服和其他公共倉庫。

私服是一種特殊的遠(yuǎn)程倉庫，它是架設(shè)在局域網(wǎng)內(nèi)的倉庫服務(wù)，私服代理廣域網(wǎng)上的遠(yuǎn)程倉庫，供局域網(wǎng)內(nèi)的Maven用戶使用。

上圖是搭建私服的示意圖。私服會(huì)將其他公共倉庫的 jar 緩存到搭建的服務(wù)器上，局域網(wǎng)內(nèi)的用戶還可以將構(gòu)建的項(xiàng)目直接放到私服上供其他開發(fā)人員使用。

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

比如 Maven 的中央倉庫部署在國外，國內(nèi)訪問外網(wǎng)速度不夠，我們可以在國內(nèi)架設(shè) Maven 的公共倉庫。

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

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

在安裝好 maven 的基礎(chǔ)上，進(jìn)入 maven 的安裝目錄，可以看到如下的目錄結(jié)構(gòu)：

bin : mvn 的一些腳本文件

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

conf : 配置文件

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

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

強(qiáng)烈建議遵循以上規(guī)范，避免不必要的麻煩。

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

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

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


    /path/to/local/repo

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

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

在repositories元素下，可以使用repository子 元素聲明一個(gè)或者多個(gè)遠(yuǎn)程倉庫。

＜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
    

以下網(wǎng)站提供 Maven 倉庫搜索功能。

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

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

一般我就用最后一個(gè)搜索。

現(xiàn)在有了倉庫統(tǒng)一保管這些 jar 包，剩下的問題就是怎么取了。

不知道你有沒有取快遞的經(jīng)驗(yàn)。我們可以這些 jar 包想象成是快遞，倉庫中保管著這些快遞。我們?nèi)フJ(rèn)領(lǐng)快遞需要依靠快遞單來確定，一張快遞單上會(huì)有單號(hào)、我們的姓名、手機(jī)號(hào)等信息。依靠這些信息就不會(huì)領(lǐng)錯(cuò)快遞了。

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

Maven 項(xiàng)目規(guī)定的項(xiàng)目結(jié)構(gòu)是這樣的：

src/main/java —— 存放項(xiàng)目的.java文件

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

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

src/test/resources —— 測(cè)試資源文件

target —— 項(xiàng)目輸出位置

pom.xml——maven項(xiàng)目核心配置文件

每個(gè) maven 項(xiàng)目都有 pom.xml 文件。Maven坐標(biāo)為各種構(gòu)件引入了秩序，任何一個(gè)構(gòu)件都必須明確定義自己的坐標(biāo)。

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

groupId：定義當(dāng)前Maven項(xiàng)目隸屬的實(shí)際項(xiàng)目，通常為域名反寫

artifactId：該元素定義實(shí)際項(xiàng)目中的一個(gè) Maven項(xiàng)目（模塊），推薦的做法是使用實(shí)際項(xiàng)目名稱作為artifactId的前綴。

version：該元素定義Maven項(xiàng)目當(dāng)前所處的 版本，

packaging：該元素定義Maven項(xiàng)目的打包方 式。當(dāng)不定義packaging的時(shí)候，Maven會(huì)使用默認(rèn)值jar。

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

通過坐標(biāo)系我們來保證項(xiàng)目在 Maven 倉庫中的唯一性，每次取也不會(huì)取錯(cuò)了。

我們自己項(xiàng)目需要用別人的 jar 包，比如 spring。這就是我們的項(xiàng)目依賴于 spring，因此我們通過 pom 來配置這樣的依賴關(guān)系，這樣就能讓項(xiàng)目有清晰的結(jié)構(gòu)。

依賴的關(guān)系用用標(biāo)簽來表示依賴：

上圖說明該項(xiàng)目依賴了 hibernate 等

現(xiàn)在來考慮一種情況，我們?cè)陧?xiàng)目開發(fā)的過程中用到了 junit 進(jìn)行測(cè)試，也就是說我們的項(xiàng)目依賴于 junit。在項(xiàng)目構(gòu)建的過程中我們會(huì)把 junit 也打包在項(xiàng)目中。但是在生產(chǎn)環(huán)境中完全沒有必要用到 junit，我們并不想將它發(fā)布到生產(chǎn)環(huán)境中。

我們可以每次在發(fā)布項(xiàng)目之前把他刪除了對(duì)么？那如果依賴 servlet-api，我們只有在編譯和測(cè)試項(xiàng)目的時(shí)候需要該依賴，但在運(yùn)行項(xiàng)目的時(shí)候，由于容器已經(jīng)提供，也不需要 Maven 重復(fù)地引入一遍。

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

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

compile：編譯依賴范圍，使用此依賴范圍對(duì)于編譯、測(cè)試、運(yùn)行三種classpath都有效，即在編譯、測(cè)試和運(yùn)行時(shí)都要使用該依賴jar包；

test：測(cè)試依賴范圍，只對(duì)測(cè)試有效，表明只在測(cè)試的時(shí)候需要，在編譯和運(yùn)行時(shí)將無法使用該類依賴，如 junit；

provided：已提供依賴范圍。編譯和測(cè)試有效，運(yùn)行無效。如servlet-api，在項(xiàng)目運(yùn)行時(shí)，tomcat等容器已經(jīng)提供，無需Maven重復(fù)引入；

runtime：運(yùn)行時(shí)依賴范圍。測(cè)試和運(yùn)行有效，編譯無效。如 jdbc 驅(qū)動(dòng)實(shí)現(xiàn)，編譯時(shí)只需接口，測(cè)試或運(yùn)行時(shí)才需要具體的 jdbc 驅(qū)動(dòng)實(shí)現(xiàn)；

system：系統(tǒng)依賴范圍，使用system范圍的依賴時(shí)必須通過systemPath元素顯示地指定依賴文件的路徑，不依賴Maven倉庫解析，所以可能會(huì)造成建構(gòu)的不可移植，謹(jǐn)慎使用。

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

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

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

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

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

再來看一種情況，A 依賴于 B，且 B 將他的依賴 C 傳遞給了 A。但是 A 依賴了 C 的另一個(gè)版本。這個(gè)時(shí)候 A 可以主動(dòng)排除 B 給的 C 依賴，轉(zhuǎn)而使用自己需要的版本，這就用到了exclusions標(biāo)簽。

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

所以我用主動(dòng)和被動(dòng)的方式來區(qū)分他們。

接上面的問題，如果 A 和 B 依賴 C 的不同版本，而且既沒有配置可選依賴也沒有配置排除依賴。兩個(gè)版本都被解析顯然是不對(duì)的，因?yàn)槟菚?huì)造成依賴重復(fù)，因此必須選擇一個(gè)。

路徑最近者優(yōu)先。如果直接與間接依賴中包含有同一個(gè)坐標(biāo)不同版本的資源依賴，以直接依賴的版本為準(zhǔn)。

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

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

Maven的生命周期就是為了對(duì)所有的構(gòu)建過程進(jìn)行抽象和統(tǒng)一。這個(gè)生命周期包含了項(xiàng)目的 清理、初始化、編譯、測(cè)試、打包、集成測(cè)試、 驗(yàn)證、部署和站點(diǎn)生成等幾乎所有構(gòu)建步驟。

初學(xué)者往往會(huì)以為Maven的生命周期是一個(gè)整體，其實(shí)不然。Maven擁有三套相互獨(dú)立的生命周期，它們分別為clean、default和site。clean生命周期的目的是清理項(xiàng)目，default生命周期的目的是構(gòu)建項(xiàng)目，而site生命周期的目的是建立項(xiàng)目站點(diǎn)。

clean生命周期的目的是清理項(xiàng)目，它包含三個(gè)階段：

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

clean 移除所有上一次構(gòu)建生成的文件

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

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

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

validate

generate-sources

process-sources

generate-resources

process-resources 復(fù)制并處理資源文件，至目標(biāo)目錄，準(zhǔn)備打包。

compile 編譯項(xiàng)目的源代碼。

process-classes

generate-test-sources

process-test-sources

generate-test-resources

process-test-resources 復(fù)制并處理資源文件，至目標(biāo)測(cè)試目錄。

test-compile 編譯測(cè)試源代碼。

process-test-classes

test 使用合適的單元測(cè)試框架運(yùn)行測(cè)試。這些測(cè)試代碼不會(huì)被打包或部署。

prepare-package

package 接受編譯好的代碼，打包成可發(fā)布的格式，如 JAR 。

pre-integration-test

integration-test

post-integration-test

verify

install 將包安裝至本地倉庫，以讓其它項(xiàng)目依賴。

deploy 將最終的包復(fù)制到遠(yuǎn)程的倉庫，以讓其它開發(fā)人員與項(xiàng)目共享。

運(yùn)行任何一個(gè)階段的時(shí)候，它前面的所有階段都會(huì)被運(yùn)行，這也就是為什么我們運(yùn)行mvn install 的時(shí)候，代碼會(huì)被編譯，測(cè)試，打包。此外，Maven的插件機(jī)制是完全依賴Maven的生命周期的，因此理解生命周期至關(guān)重要。

site生命周期的目的是建立和發(fā)布項(xiàng)目站點(diǎn)，Maven能夠基于POM所包含的信息，自動(dòng)生成一個(gè)友好的站點(diǎn)，方便團(tuán)隊(duì)交流和發(fā)布項(xiàng)目信息。

pre-site 執(zhí)行一些需要在生成站點(diǎn)文檔之前完成的工作

site 生成項(xiàng)目的站點(diǎn)文檔

post-site 執(zhí)行一些需要在生成站點(diǎn)文檔之后完成的工作，并且為部署做準(zhǔn)備

site-deploy 將生成的站點(diǎn)文檔部署到特定的服務(wù)器上

這里經(jīng)常用到的是site階段和site-deploy階段，用以生成和發(fā)布Maven站點(diǎn)，這可是Maven相當(dāng)強(qiáng)大的功能，Manager比較喜歡，文檔及統(tǒng)計(jì)數(shù)據(jù)自動(dòng)生成，很好看。

mvn clean：該命令調(diào)用clean生命周期的clean階段。實(shí)際執(zhí)行的階段為clean生命周期的 pre-clean和clean階段。

mvn test：該命令調(diào)用default生命周期的test階段。實(shí)際執(zhí)行的階段為default生命周期的 validate、initialize等，直到test的所有階段。這也解釋了為什么在執(zhí)行測(cè)試的時(shí)候，項(xiàng)目的代碼能夠自動(dòng)得以編譯。

mvn clean install：該命令調(diào)用clean生命周期 的clean階段和default生命周期的install階段。

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

軟件設(shè)計(jì)人員往往會(huì)采用各種方式對(duì)軟件劃分模塊，以得到更清晰的設(shè)計(jì)及更高的重用性。當(dāng)把Maven應(yīng)用到實(shí)際項(xiàng)目中的時(shí)候，也需要將項(xiàng)目分成不同的模塊。

簡(jiǎn)單的說就是有 A,B 兩個(gè)模塊，現(xiàn)在想要將他們統(tǒng)一管理。Maven 的聚合特性能夠把項(xiàng)目的各個(gè)模塊聚合在一起構(gòu)建，而Maven的繼承特性則能幫助抽取各模塊相同的依賴和插件等配置，在簡(jiǎn)化POM的同時(shí)，還能促進(jìn)各個(gè)模塊配置的一致性。

兩個(gè)子模塊希望同時(shí)構(gòu)建。這時(shí)，一個(gè)簡(jiǎn)單的需求就會(huì)自然而然地顯現(xiàn)出來：我們會(huì)想要一次構(gòu)建兩個(gè)項(xiàng)目，而不是到兩個(gè)模塊的目錄下分別執(zhí)行mvn命令。Maven聚合（或者稱為多模塊）這一特性就是為該需求服務(wù)的。

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

他們的配置很簡(jiǎn)單，我們最好遵循規(guī)范。

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
    
    ...

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

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

這樣只需要構(gòu)建聚合 pom 文件即可同時(shí)構(gòu)建在其管理下的多個(gè)子模塊。

消除重復(fù)。在面向?qū)ο笫澜缰?，程序員可以使用類繼承在一定程度上消除重復(fù)，在Maven的世界 中，也有類似的機(jī)制能讓我們抽取出重復(fù)的配 置，這就是POM的繼承。

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

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

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

我們可以使用dependencyManagement 標(biāo)簽。

父類 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中聲明了各個(gè)子模塊，子模塊之間有的會(huì)需要相互引用，有的卻并不需要。所以在父類中統(tǒng)一配置各個(gè)子模塊的groupId,artifactId,version等基本信息。

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

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

    
        com.shuiyujie.fu
        sop
        1.0-SNAPSHOT
    

    4.0.0
    api

    
        
            ${project.parent.groupId}
            fu-persist
        
    

Maven 的核心思想是約定優(yōu)于配置。

首先，Maven 約定了項(xiàng)目的結(jié)構(gòu)，我們不需要配置 Maven 編譯、打包等操作時(shí)文件的位置。統(tǒng)一的項(xiàng)目結(jié)構(gòu)降低了學(xué)習(xí)的成本，讓我能將精力集中到了項(xiàng)目本身。

其次，Maven 抽象了項(xiàng)目構(gòu)建的過程，將其分成一個(gè)個(gè)生命周期進(jìn)行管理。通過命令和插件的形式進(jìn)一步簡(jiǎn)化操作，又讓我們從繁瑣的操作解放出來。

《Maven 實(shí)戰(zhàn)》

Maven遠(yuǎn)程倉庫的各種配置

本文大部分內(nèi)容來自于《Maven 實(shí)戰(zhàn)》一書，想要了解一手信息強(qiáng)烈建議閱讀。網(wǎng)上的其他文章基本上都是摘抄《Maven 實(shí)戰(zhàn)》的部分內(nèi)容。
所以還想說一遍：發(fā)現(xiàn)一本好書就像發(fā)現(xiàn)了一座寶藏。