原本地址：Maven入門，讀完這篇就夠了
部落格地址：tengj.top/
前言
夜空中最亮的星，2018請照亮我前行~ Maven是我們日常開發都會用到的，新年第一天，把看過的Maven基礎概念做了整理，作為入門和查閱使用。
正文
Maven概念
Maven作為一個構建工具，不僅能幫我們自動化構建，還能夠抽象構建過程，提供構建任務實現;它跨平臺，對外提供了一致的操作介面，這一切足以使它成為優秀的、流行的構建工具。
Maven不僅是構建工具，還是一個依賴管理工具和專案管理工具，它提供了中央倉庫，能幫我自動下載構件。
maven的安裝
一：因為本人是window系統，所以這裡只介紹window下如何安裝，在安裝Maven之前，先確認已經安裝了JDK.
二：接著去Maven官網下載介面下載想要的版本解壓到你想要的目錄就行
三：最後設定一下環境變數，將Maven安裝配置到作業系統環境中，主要就是配置M2_HOME 和PATH兩項，如圖
都搞定後，驗證一下，開啟doc輸入 mvn -v如何得到下面資訊就說明配置成功了
maven目錄
- bin目錄： 該目錄包含了mvn執行的指令碼，這些指令碼用來配置java命令，準備好classpath和相關的Java系統屬性，然後執行Java命令。
- boot目錄: 該目錄只包含一個檔案，該檔案為plexus-classworlds-2.5.2.jar。plexus-classworlds是一個類載入器框架，相對於預設的java類載入器，它提供了更加豐富的語法以方便配置，Maven使用該框架載入自己的類庫。
- conf目錄: 該目錄包含了一個非常重要的檔案settings.xml。直接修改該檔案，就能在機器上全域性地定製Maven的行為，一般情況下，我們更偏向於複製該檔案至~/.m2/目錄下（~表示使用者目錄），然後修改該檔案，在使用者範圍定製Maven的行為。
- lib目錄: 該目錄包含了所有Maven執行時需要的Java類庫，Maven本身是分模組開發的，因此使用者能看到諸如maven-core-3.0.jar、maven-model-3.0.jar之類的檔案，此外這裡還包含一些Maven用到的第三方依賴如commons-cli-1.2.jar、commons-lang-2.6.jar等等。
Maven常用命令說明
**mvn clean：**表示執行清理操作（會預設把target資料夾中的資料清理）。 **mvn clean compile：**表示先執行清理之後執行編譯，會將程式碼編譯到target資料夾中。 **mvn clean test：**執行清理和測試。 **mvn clean package：**執行清理和打包。 **mvn clean install：**執行清理和安裝，會將打好的包安裝到本地倉庫中，以便其他的專案可以呼叫。 **mvn clean deploy：**執行清理和釋出（釋出到私服上面）。
上面的命令大部分都是連寫的，大家也可以拆分分別執行，這是活的，看個人喜好以及使用需求，Eclipse Run as對maven專案會提供常用的命令。
設定http代理
編輯seeting.xml檔案 有時候你所在的公司基於安全因素考慮，要求你使用通過安全認證的代理訪問因特網。這種情況下，就需要為Maven配置HTTP代理，才能讓它正常訪問外部倉庫，以下載所需要的資源。首先確認自己無法直接訪問公共的maven中央倉庫，直接執行命令ping repo1.maven.org可以檢查網路。如果真的需要代理，先檢查一下代理伺服器是否暢通。比如現在有一個IP地址為218.14.227.197，埠為3128的代理服務，我們可以執行telnet 218.14.227.197 3128來檢測該地址的該埠是否暢通。如果得到出錯資訊，需要先獲取正確的代理服務資訊，如果telnet連線正確，則輸入ctrl+]，然後q，回車，退出即可。
檢查完畢之後，編輯~/.m2/settings.xml檔案(如果沒有該檔案，則複製$M2_HOME/conf/settings.xml)。新增代理配置如下：
<settings>
...
<proxies>
<proxy>
<id>my-proxy</id>
<active>true</active>
<protocol>http</protocol>
<host>218.14.227.197</host>
<port>3128</port>
<!--
<username>***</username>
<password>***</password>
<nonProxyHosts>
repository.mycom.com|*.google.com
</nonProxyHosts>
-->
</proxy>
</proxies>
...
</settings>
複製程式碼這段配置十分簡單，proxies下可以有多個proxy元素，如果宣告瞭多個proxy元素，則預設情況下第一個被啟用的proxy會生效。這裡宣告瞭一個id為my-proxy的代理，active的值為true表示啟用該代理，protocol表示使用的代理協議，這裡是http。當然，最重要的是指定正確的主機名(host元素)和埠(port元素)。上述xml配置中註釋掉了username,password,nonProxyHosts幾個元素。當代理服務需要認證時，就需要配置username和password。nonProxyHost元素用來指定哪些主機不需要代理，可以使用"|"符號來分隔多個主機名。此外，該配置也支援萬用字元，如:*.google.com表示所有以google.com結尾的域名訪問都不要通過代理。
Maven外掛安裝，基於IDEA
博主現在使用IDEA來開發的，所以這裡介紹一下IDEA中如何配置引入我們上面下載好的Maven
Maven使用
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.tengj</groupId>
<artifactId>springBootDemo1</artifactId>
<version>0.0.1-SNAPSHOT</version>
<name>springBootDemo1</name>
</project>
複製程式碼程式碼的第一行是XML頭，指定了該xml文件的版本和編碼方式。 project是所有pom.xml的根元素，它還宣告瞭一些POM相關的名稱空間及xsd元素。 根元素下的第一個子元素modelVersion指定了當前的POM模型的版本，對於Maven3來說，它只能是4.0.0 程式碼中最重要是包含了groupId,artifactId和version了。這三個元素定義了一個專案基本的座標，在Maven的世界，任何的jar、pom或者jar都是以基於這些基本的座標進行區分的。
groupId定義了專案屬於哪個組，隨意命名，比如谷歌公司的myapp專案，就取名為 com.google.myapp
artifactId定義了當前Maven專案在組中唯一的ID,比如定義hello-world。
version指定了專案當前的版本0.0.1-SNAPSHOT,SNAPSHOT意為快照，說明該專案還處於開發中，是不穩定的。
name元素生命了一個對於使用者更為友好的專案名稱，雖然這不是必須的，但還是推薦為每個POM宣告name,以方便資訊交流
依賴的配置
<project>
...
<dependencies>
<dependency>
<groupId>實際專案</groupId>
     <artifactId>模組</artifactId>
     <version>版本</version>
     <type>依賴型別</type>
     <scope>依賴範圍</scope>
     <optional>依賴是否可選</optional>
     <!—主要用於排除傳遞性依賴-->
     <exclusions>
     <exclusion>
        <groupId>…</groupId>
          <artifactId>…</artifactId>
       </exclusion>
     </exclusions>
  </dependency>
<dependencies>
...
</project>
複製程式碼根元素project下的dependencies可以包含一個或者多個dependency元素，以宣告一個或者多個專案依賴。每個依賴可以包含的元素有：
- grounpId、artifactId和version:以來的基本座標，對於任何一個依賴來說，基本座標是最重要的，Maven根據座標才能找到需要的依賴。
- type:依賴的型別，對於專案座標定義的packaging。大部分情況下，該元素不必宣告，其預設值為jar
- scope:依賴的範圍
- optional:標記依賴是否可選
- exclusions:用來排除傳遞性依賴
依賴範圍
依賴範圍就是用來控制依賴和三種classpath(編譯classpath，測試classpath、執行classpath)的關係，Maven有如下幾種依賴範圍：
- **compile:**編譯依賴範圍。如果沒有指定，就會預設使用該依賴範圍。使用此依賴範圍的Maven依賴，對於編譯、測試、執行三種classpath都有效。典型的例子是spring-code,在編譯、測試和執行的時候都需要使用該依賴。
- test: 測試依賴範圍。使用次依賴範圍的Maven依賴，只對於測試classpath有效，在編譯主程式碼或者執行專案的使用時將無法使用此依賴。典型的例子是Jnuit,它只有在編譯測試程式碼及執行測試的時候才需要。
- **provided:**已提供依賴範圍。使用此依賴範圍的Maven依賴，對於編譯和測試classpath有效，但在執行時候無效。典型的例子是servlet-api,編譯和測試專案的時候需要該依賴，但在執行專案的時候，由於容器以及提供，就不需要Maven重複地引入一遍。
- **runtime:**執行時依賴範圍。使用此依賴範圍的Maven依賴，對於測試和執行classpath有效，但在編譯主程式碼時無效。典型的例子是JDBC驅動實現，專案主程式碼的編譯只需要JDK提供的JDBC介面，只有在執行測試或者執行專案的時候才需要實現上述介面的具體JDBC驅動。
- **system:**系統依賴範圍。該依賴與三種classpath的關係，和provided依賴範圍完全一致，但是，使用system範圍的依賴時必須通過systemPath元素顯示地指定依賴檔案的路徑。由於此類依賴不是通過Maven倉庫解析的，而且往往與本機系統繫結，可能構成構建的不可移植，因此應該謹慎使用。systemPath元素可以引用環境變數，如：
<dependency>
<groupId>javax.sql</groupId>
<artifactId>jdbc-stdext</artifactId>
<Version>2.0</Version>
<scope>system</scope>
<systemPath>${java.home}/lib/rt.jar</systemPath>
</dependency>
複製程式碼- **import:**匯入依賴範圍。該依賴範圍不會對三種classpath產生實際的影響。 上述除import以外的各種依賴範圍與三種classpath的關係如下:
傳遞性依賴
比如一個account-email專案為例，account-email有一個compile範圍的spring-code依賴，spring-code有一個compile範圍的commons-logging依賴，那麼commons-logging就會成為account-email的compile的範圍依賴，commons-logging是account-email的一個傳遞性依賴
有了傳遞性依賴機制，在使用Spring Framework的時候就不用去考慮它依賴了什麼，也不用擔心引入多餘的依賴。Maven會解析各個直接依賴的POM，將那些必要的間接依賴，以傳遞性依賴的形式引入到當前的專案中。
依賴範圍
假設A依賴於B,B依賴於C，我們說A對於B是第一直接依賴，B對於C是第二直接依賴，A對於C是傳遞性依賴。第一直接依賴和第二直接依賴的範圍決定了傳遞性依賴的範圍，如下圖所示，最左邊一行表示第一直接依賴範圍，最上面一行表示第二直接依賴範圍，中間的交叉單元格則表示傳遞依賴範圍。
從上圖中，我們可以發現這樣的規律：
- 當第二直接依賴的範圍是compile的時候，傳遞性依賴的範圍與第一直接依賴的範圍一致；
- 當第二直接依賴的範圍是test的時候，依賴不會得以傳遞；
- 當第二直接依賴的範圍是provided的時候，只傳遞第一直接依賴範圍也為provided的依賴，切傳遞依賴的範圍同樣為provided;
- 當第二直接依賴的範圍是runtime的時候，傳遞性依賴的範圍與第一直接依賴的範圍一致，但compile列外，此時傳遞性依賴範圍為runtime.
## 依賴調解 有時候，當傳遞性依賴造成為題的時候，就需要清楚地知道該傳遞性依賴是從哪條依賴路徑引入的。這就是依賴調解的作用，依賴調解有兩大原則： 1. 路徑最近者優先 比如專案有A有這樣的依賴關係：A->B->C->X(1.0)、A->D->X(2.0),X是A的傳遞性依賴，但是兩條依賴路徑上有兩個版本的X，所以根據第一原則，A->D->X(2.0)路徑短，所以X(2.0)會被解析使用 2. 第一宣告者優先 如果路徑都一樣長的話，第一原則就不行了，比如 A->B->Y(1.0)、A->C->Y(2.0),Y(1.0)和Y(2.0)的路徑一樣，所以這時候根據第二原則，先宣告的被解析。
## 可選依賴
如圖，專案中A依賴B，B依賴於X和Y，如果所有這三個的範圍都是compile的話，那麼X和Y就是A的compile範圍的傳遞性依賴，但是如果我想X,Y不作為A的傳遞性依賴，不給他用的話。就需要下面提到的配置可選依賴。
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.juvenxu.mvnbook</groupId>
<artifactId>project-b</artifactId>
<version>1.0.0</version>
<dependencies>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.10</version>
<optional>true</optional>
</dependency>
<dependency>
<groupId>postgresql</groupId>
<artifactId>postgresql</groupId>
<version>8.4-701.jdbc3</version>
<optional>true</optional>
</dependency>
</dependencies>
</project>
複製程式碼配置也簡單，在依賴裡面新增
<optional>true</optional>
複製程式碼就表示可選依賴了，這樣A如果想用X,Y就要直接顯示的新增依賴了。
排除依賴
有時候你引入的依賴中包含你不想要的依賴包，你想引入自己想要的，這時候就要用到排除依賴了，比如下圖中spring-boot-starter-web自帶了logback這個日誌包，我想引入log4j2的，所以我先排除掉logback的依賴包，再引入想要的包就行了
排除依賴程式碼結構：
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-logging</artifactId>
</exclusion>
</exclusions>
複製程式碼這裡注意：宣告exclustion的時候只需要groupId和artifactId，而不需要version元素，這是因為只需要groupId和artifactId就能唯一定位依賴圖中的某個依賴。
歸類依賴
有時候我們引入的很多依賴包，他們都來自同一個專案的不同模組，所以他們的版本號都一樣，這時候我們可以用屬性來統一管理版本號
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.juven.mvnbook.account</groupId>
<artifactId>accout-email</artifactId>
<version>1.0.0-SNAPSHOT</version>
<properties>
<springframework.version>1.5.6</springframework.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${springframework.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>${springframework.version}</version>
</dependency>
</dependencies>
</project>
複製程式碼如圖所示，先通過
</properties>
這裡定義你先要的版本
</properties>
複製程式碼來定義，然後在下面依賴使用${}來引入你的屬性。
倉庫
這節將介紹倉庫的由來、佈局、分類、配置、內部工作機制、映象等概念
倉庫的由來
在Maven世界中，任何一個依賴、外掛或者專案構建的輸出，都可以稱為構件。得益於座標機制，任何Maven專案使用任何一個構件的方式都是完全相同的。在此基礎上，Maven可以在某個位置統一儲存所有Maven專案共享的構件，這個統一的位置就是倉庫。
實際的Maven專案將不再各自儲存其依賴檔案，它們只需要宣告這些依賴的座標，在需要的時候（例如，編譯專案的時候需要將依賴加入到classpath中），Maven會自動根據座標找到倉庫中的構件，並使用它們。
為了實現重用，專案構建完畢後可生成的構件也可以安裝或者部署到倉庫中，供其他專案使用。
倉庫的佈局
任何一個構件都有其唯一的座標，根據這個座標可以定義其在倉庫中的唯一儲存路徑，這便是Maven的倉庫佈局方式。 該路經與座標對應關係為groupId/artifactId/version/artifactId-version.packaging。 舉個例子，比如下面這個分頁外掛依賴如下：
<dependency>
<groupId>com.github.pagehelper</groupId>
<artifactId>pagehelper-spring-boot-starter</artifactId>
<version>1.1.0</version>
</dependency>
複製程式碼那他對應的倉庫的路徑就是這樣：
Maven倉庫是基於簡單檔案系統儲存的，我們也理解其儲存方式、因此，當遇到一些與倉庫相關的問題時，可以很方便的查詢相關檔案，方便定位問題。
倉庫的分類
本地倉庫
一般來說，在Maven專案目錄下，沒有諸如lib/這樣用來存放依賴檔案的目錄。當Maven在執行編譯或測試時，如果需要使用依賴檔案，它總是基於座標使用本地倉庫的依賴檔案。
預設情況下，不管在Window還是Linux下，每個使用者在自己使用者目錄下都有一個路徑名為.m2/repository/的倉庫目錄。 如果你想自定義本地倉庫目錄地址。你可以編輯檔案~/.m2/settings.xml，設定localRepository元素的值為想要的倉庫地址，例如:
<settings>
<localRepository>D:\java\repository\</localRepository>
</settings>
複製程式碼這樣，該使用者的本地倉庫地址就被設定成了 D:\java\repository\。 需要注意的是，預設情況下，~/.m2/settings.xml檔案不存在，使用者需要從Maven安裝目錄複製$M2_HOME/conf/settings.xml檔案再進行編輯。
遠端倉庫-中央倉庫
由於最原始的本地倉庫是空的，Maven必須知道至少一個可用的遠端倉庫，才能在執行Maven命令的時候下載到需要的構件。中央倉庫就是這樣一個預設的遠端倉庫，Maven的安裝檔案自帶了中央倉庫的配置。
中央倉庫包含了這個世界上絕大多數流行的開源Java構件，以及原始碼、作者資訊、SCM,資訊、許可證資訊等，每個月這裡都會接受全世界Java程式設計師大概1億次的訪問，它對全世界Java開發者的貢獻由此可見一斑。
遠端倉庫-私服
私服是一種特殊的遠端倉庫，它是架設在區域網內的倉庫服務，私服代理廣域網上的遠端倉庫，供區域網內的Maven使用者使用。當Maven需要下載構件的時候，它從私服請求，如果私服上不存在該構件，則從外部的遠端倉庫下載，快取在私服上之後，再為Maven的下載請求提供服務。因此，一些無法從外部倉庫下載到的構件也能從本地上傳到私服上供大家使用。 私服的好處：
- 節省自己的外網速度
- 加速Maven構建
- 部署第三方構建
- 提高穩定性，增強控制
- 降低中央倉庫的負荷
遠端倉庫的配置
在平時的開發中，我們往往不會使用預設的中央倉庫，預設的中央倉庫訪問的速度比較慢，訪問的人或許很多，有時候也無法滿足我們專案的需求，可能專案需要的某些構件中央倉庫中是沒有的，而在其他遠端倉庫中有，如JBoss Maven倉庫。這時，可以在pom.xml中配置該倉庫，程式碼如下：
<!-- 配置遠端倉庫 -->
<repositories>
<repository>
<id>jboss</id>
<name>JBoss Repository</name>
<url>http://repository.jboss.com/maven2/</url>
<releases>
<enabled>true</enabled>
<updatePolicy>daily</updatePolicy>
</releases>
<snapshots>
<enabled>false</enabled>
<checksumPolicy>warn</checksumPolicy>
</snapshots>
<layout>default</layout>
</repository>
</repositories>
複製程式碼- **repository:**在repositories元素下，可以使用repository子元素宣告一個或者多個遠端倉庫。
- **id：**倉庫宣告的唯一id，尤其需要注意的是，Maven自帶的中央倉庫使用的id為central，如果其他倉庫宣告也使用該id，就會覆蓋中央倉庫的配置。
- **name：**倉庫的名稱，讓我們直觀方便的知道倉庫是哪個，暫時沒發現其他太大的含義。
- **url：**指向了倉庫的地址，一般來說，該地址都基於http協議，Maven使用者都可以在瀏覽器中開啟倉庫地址瀏覽構件。
- releases和snapshots：用來控制Maven對於釋出版構件和快照版構件的下載許可權。需要注意的是enabled子元素，該例中releases的enabled值為true，表示開啟JBoss倉庫的釋出版本下載支援，而snapshots的enabled值為false，表示關閉JBoss倉庫的快照版本的下載支援。根據該配置，Maven只會從JBoss倉庫下載釋出版的構件，而不會下載快照版的構件。
- **layout：**元素值default表示倉庫的佈局是Maven2及Maven3的預設佈局，而不是Maven1的佈局。基本不會用到Maven1的佈局。
- 其他：對於releases和snapshots來說，除了enabled，它們還包含另外兩個子元素updatePolicy和checksumPolicy。
1：元素updatePolicy用來配置Maven從遠處倉庫檢查更新的頻率，預設值是daily，表示Maven每天檢查一次。其他可用的值包括：never-從不檢查更新；always-每次構建都檢查更新；interval：X-每隔X分鐘檢查一次更新（X為任意整數）。
2：元素checksumPolicy用來配置Maven檢查校驗和檔案的策略。當構建被部署到Maven倉庫中時，會同時部署對應的檢驗和檔案。在下載構件的時候，Maven會驗證校驗和檔案，如果校驗和驗證失敗，當checksumPolicy的值為預設的warn時，Maven會在執行構建時輸出警告資訊，其他可用的值包括：fail-Maven遇到校驗和錯誤就讓構建失敗；ignore-使Maven完全忽略校驗和錯誤。
遠端倉庫的認證
大部分的遠端倉庫不需要認證，但是如果是自己內部使用，為了安全起見，還是要配置認證資訊的。 配置認證資訊和配置遠端倉庫不同，遠端倉庫可以直接在pom.xml中配置，但是認證資訊必須配置在settings.xml檔案中。這是因為pom往往是被提交到程式碼倉庫中供所有成員訪問的，而settings.xml一般只存在於本機。因此，在settings.xml中配置認證資訊更為安全。
<settings>
2 ...
3 <!--配置遠端倉庫認證資訊-->
4 <servers>
5 <server>
6 <id>releases</id>
7 <username>admin</username>
8 <password>admin123</password>
9 </server>
10 </servers>
11 ...
12 </settings>
複製程式碼這裡除了配置賬號密碼之外，值關鍵的就是id了，這個id要跟你在pom.xml裡面配置的遠端倉庫repository的id一致，正是這個id將認證資訊與倉庫配置聯絡在了一起。
部署構件至遠端倉庫
我們自己搭建遠端倉庫的目的就是為了可以方便部署我們自己專案的構件以及一些無法從外部倉庫直接獲取的構件。這樣才能在開發時，供其他對團隊成員使用。 Maven除了能對專案進行編譯、測試、打包之外，還能將專案生成的構件部署到遠端倉庫中。首先，需要編輯專案的pom.xml檔案。配置distributionManagement元素，程式碼如下：
<distributionManagement>
<repository>
<id>releases</id>
<name>public</name>
<url>http://59.50.95.66:8081/nexus/content/repositories/releases</url>
</repository>
<snapshotRepository>
<id>snapshots</id>
<name>Snapshots</name>
<url>http://59.50.95.66:8081/nexus/content/repositories/snapshots</url>
</snapshotRepository>
</distributionManagement>
複製程式碼看程式碼，從命名上就看的出來區別，repository表示表示釋出版本（穩定版本）構件的倉庫，snapshotRepository表示快照版本（開發測試版本）的倉庫。這兩個元素都需要配置id、name和url，id為遠端倉庫的唯一標識，name是為了方便人閱讀，關鍵的url表示該倉庫的地址。
配置好了就執行命令mvn clean deploy，Maven就會將專案構建輸出的構件部署到配置對應的遠端倉庫，如果專案當前的版本是快照版本，則部署到快照版本的倉庫地址，否則就部署到釋出版本的倉庫地址。 當前專案是快照還是釋出版本是通過 true 這個來區分的。忘記的同學在看看上面的## 遠端倉庫的配置。
映象
如果倉庫X可以提供倉庫Y儲存的所有內容，那麼就可以認為X是Y的一個映象。用過Maven的都知道，國外的中央倉庫用起來太慢了，所以選擇一個國內的映象就很有必要，我推薦國內的阿里雲映象。 阿里雲映象：配置很簡單，修改conf資料夾下的settings.xml檔案，新增如下映象配置：
<mirrors>
<mirror>
<id>alimaven</id>
<name>aliyun maven</name>
<url>http://maven.aliyun.com/nexus/content/groups/public/</url>
<mirrorOf>central</mirrorOf>
</mirror>
</mirrors>
複製程式碼上例子中，的值為central,表示該配置為中央庫的映象，任何對於中央倉庫的請求都會轉至該映象，使用者也可以用同樣的方法配置其他倉庫的映象
這裡介紹下<mirrorOf>配置的各種選項
<mirrorOf>*<mirrorOf>:匹配所有遠端倉庫。<mirrorOf>external:*<mirrorOf>:匹配所有遠端倉庫，使用localhost的除外，使用file://協議的除外。也就是說，匹配所有不在本機上的遠端倉庫。<mirrorOf>repo1,repo2<mirrorOf>:匹配倉庫repo1h和repo2，使用逗號分隔多個遠端倉庫。<mirrorOf>*,!repo1<mirrorOf>:匹配所有遠端倉庫，repo1除外，使用感嘆號將倉庫從匹配中排除。
需要注意的是，由於映象倉庫完全遮蔽了被映象倉庫，當映象倉庫不穩定或者停止服務的時候，Maven仍將無法訪問被映象倉庫，因而將無法下載構件。
倉庫服務搜尋
這裡介紹2個提供倉庫服務搜尋的地址：
- Sonatype Nexus：https://repository.sonatype.org/
- MVNrepository：http://mvnrepository.com/
總結
暫時先這樣，後面繼續補充更新本篇，關於私服搭建的會另外開一片介紹。
本篇基於《Maven實戰》整理提煉。需要電子書小夥伴可關注博主微信公眾號：嘟爺java超神學堂（javaLearn）回覆關鍵字 maven獲取電子書。
