Maven入門，讀完這篇就夠了

時間  2019-11-07
標籤 maven 入門 讀完 夠了 欄目 Maven 简体版
原文   原文鏈接

本來地址：Maven入門，讀完這篇就夠了
博客地址：tengj.top/php

前言

夜空中最亮的星，2018請照亮我前行~ Maven是咱們平常開發都會用到的，新年第一天，把看過的Maven基礎概念作了整理，做爲入門和查閱使用。java

正文

Maven概念

Maven做爲一個構建工具，不只能幫咱們自動化構建，還可以抽象構建過程，提供構建任務實現;它跨平臺，對外提供了一致的操做接口，這一切足以使它成爲優秀的、流行的構建工具。mysql

Maven不只是構建工具，仍是一個依賴管理工具和項目管理工具，它提供了中央倉庫，能幫我自動下載構件。git

maven的安裝

一：由於本人是window系統，因此這裏只介紹window下如何安裝，在安裝Maven以前，先確認已經安裝了JDK. 程序員

image.png

二：接着去Maven官網下載界面下載想要的版本解壓到你想要的目錄就行 github

image.png

image.png

三：最後設置一下環境變量，將Maven安裝配置到操做系統環境中，主要就是配置M2_HOME 和PATH兩項，如圖 web

image.png

都搞定後，驗證一下，打開doc輸入 mvn -v如何獲得下面信息就說明配置成功了 spring

image.png

maven目錄

image.png

  • 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：**運行清理和發佈（發佈到私服上面）。sql

上面的命令大部分都是連寫的，你們也能夠拆分分別執行，這是活的，看我的喜愛以及使用需求，Eclipse Run as對maven項目會提供經常使用的命令。apache

設置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

image.png

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>
&emsp;&emsp;&emsp;&emsp; <artifactId>模塊</artifactId>
&emsp;&emsp;&emsp;&emsp; <version>版本</version>
&emsp;&emsp;&emsp;&emsp; <type>依賴類型</type>
&emsp;&emsp;&emsp;&emsp; <scope>依賴範圍</scope>
&emsp;&emsp;&emsp;&emsp; <optional>依賴是否可選</optional>
&emsp;&emsp;&emsp;&emsp; <!—主要用於排除傳遞性依賴-->
&emsp;&emsp;&emsp;&emsp; <exclusions>
&emsp;&emsp;&emsp;&emsp;     <exclusion>
&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;    <groupId>…</groupId>
&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp; <artifactId>…</artifactId>
&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;</exclusion>
&emsp;&emsp;&emsp;&emsp; </exclusions>
&emsp;&emsp;</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的關係以下:

image.png

傳遞性依賴

好比一個account-email項目爲例，account-email有一個compile範圍的spring-code依賴，spring-code有一個compile範圍的commons-logging依賴，那麼commons-logging就會成爲account-email的compile的範圍依賴，commons-logging是account-email的一個傳遞性依賴

image.png

有了傳遞性依賴機制，在使用Spring Framework的時候就不用去考慮它依賴了什麼，也不用擔憂引入多餘的依賴。Maven會解析各個直接依賴的POM，將那些必要的間接依賴，以傳遞性依賴的形式引入到當前的項目中。

依賴範圍

假設A依賴於B,B依賴於C，咱們說A對於B是第一直接依賴，B對於C是第二直接依賴，A對於C是傳遞性依賴。第一直接依賴和第二直接依賴的範圍決定了傳遞性依賴的範圍，以下圖所示，最左邊一行表示第一直接依賴範圍，最上面一行表示第二直接依賴範圍，中間的交叉單元格則表示傳遞依賴範圍。

image.png

從上圖中，咱們能夠發現這樣的規律：

  • 當第二直接依賴的範圍是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)的路徑同樣，因此這時候根據第二原則，先聲明的被解析。

## 可選依賴

image.png

如圖，項目中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的依賴包，再引入想要的包就好了

image.png

排除依賴代碼結構：

<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>
複製代碼

那他對應的倉庫的路徑就是這樣：

image.png

Maven倉庫是基於簡單文件系統存儲的，咱們也理解其存儲方式、所以，當遇到一些與倉庫相關的問題時，能夠很方便的查找相關文件，方便定位問題。

倉庫的分類

image.png

本地倉庫

通常來講，在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獲取電子書。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程