maven倉庫介紹

1.何為Maven倉庫
maven可以在某個位置統一存儲所有maven項目共享的構件，這個統一的位置就是倉庫。實際的Maven項目將不會各自存儲其依賴文件，它們只需要聲明這些依賴的坐標，在需要的時候(例如，編譯項目的時候需要將依賴加入到classpath中)，maven會自動根據坐標找到倉庫中的構件，并使用它們。為了實現重用，項目構建完畢后生成的構件也可以安裝或者部署到倉庫中，供其他項目使用。

2.倉庫的布局
任何一個構件都有其唯一的坐標，根據這個坐標可以定義其在倉庫中的唯一存儲路徑，這便是Maven的倉庫布局方式。例如，log4j:log4j:1.2.15這個依賴，其對應的倉庫路徑為log4j/jog4j/1.2.15/log4j-1.2.15.jar,該路徑與坐標的大致對應關系為groupId/artifactId/version/artifactId-version.packaging。

maven倉庫分類

對于maven來說，倉庫只分為兩類：本地倉庫和遠程倉庫。當maven根據坐標尋找構件的時候，它首先會查看本地倉庫，如果本地倉庫存在此構件，則直接使用；如果本地倉庫不存在此構件，或者需要查看是否有更新的構件版本，maven就會去遠程倉庫查找，發現需要的構件之后，下載到本地倉庫再使用。如果本地倉庫和遠程倉庫都沒有需要的構件，maven就會報錯。
在這個最基本分類的基礎上，還有必要介紹一些特殊的遠程倉庫。中央倉庫是maven核心自帶的遠程倉庫，它包含了絕大部分開源的構件。在默認配置下，當本地倉庫沒有maven需要的構件的時候，它就會嘗試從中央倉庫下載。私服是另一種特殊的遠程倉庫，為了節省帶寬和時間，應該在局域網內架設一個私有的倉庫服務器，用其代理所有外部的遠程倉庫。內部的項目還能部署到私服上供其他項目使用。除了中央倉庫和私服，還有很多其他公開的遠程倉庫，常見的有java.net Maven庫(http://download.java.net/maven/2/)和jboss Maven庫(http://repository.jboss.com/maven2/)等。

1.本地倉庫
默認情況下，不管是在windows還是linux上，每個用戶在自己的用戶目錄下都有一個路徑名為.m2/repository/的倉庫目錄。有時候，因為某些原因(例如C盤空間不夠)，用戶會想要自定義本地倉庫目錄地址。這時，可以編輯文件~/.m2/settings.xml，設置localRepository元素的值為想要的倉庫地址。例如：

Xml代碼??

1.?<settings>??

2.?????<localRepository>D:\java\repository\</localRepository>??

3.?</settings>??

這樣，該用戶的本地倉庫地址就被設置成了D:\java\repository\。需要注意的是，默認情況下，~/.m2/settings.xml文件是不存在的，用戶需要從Maven安裝目錄復制$M2_HOME/conf/settings.xml文件再進行編輯。
一個構件只有在本地倉庫中之后，才能由其他Maven項目使用，那么構件如何進入到本地倉庫中呢？最常見的是依賴Maven從遠程倉庫下載到本地倉庫中。還有一種常見的情況是，將本地項目的構件安裝到Maven倉庫中。例如本地有兩個項目A和B，兩者都無法從遠程倉庫獲得，而同時A又依賴于B，為了能構建A，B就必須首先得以構建并安裝到本地倉庫中。為了安裝項目，我們可以在項目中執行: mvn clean install命令。Install插件的install目標將項目的構建輸出文件安裝到本地倉庫。

2.遠程倉庫
安裝好Maven后，如果不執行任何Maven命令，本地倉庫目錄是不存在的。當用戶輸入第一條Maven命令之后，Maven才會創建本地倉庫，然后根據配置和需要，從遠程倉庫下載構件至本地倉庫。

3.中央倉庫
由于最原始的本地倉庫是空的，Maven必須知道至少一個可用的遠程倉庫，才能在執行Maven命令的時候下載到需要的構件。中央倉庫就是這樣一個默認的遠程倉庫，Maven的安裝文件自帶了中央倉庫的配置。讀者可以使用解壓工具打開jar文件$M2_HOME/lib/maven-model-builder-3.0.jar(在Maven2中，jar文件路徑類似于$M2_HOME/lib/maven-2.2.1-uber.jar),然后訪問路徑：org/apache/maven/model/pom-4.0.0.xml，可以看到如下的配置：

Xml代碼??

1.?<repositories>??

2.?????<repository>??

3.?????????<id>central</id>??

4.?????????<name>Maven?Repository?Switchboard</name>??

5.?????????<url>http://repo1.maven.org/maven2</url>??

6.?????????<layout>default</layout>??

7.?????????<snapshots>??

8.?????????????<enabled>false</enabled>??

9.?????????</snapshots>??

10.????</repository>??

11.</repositories>??

包含這段配置的文件是所有Maven項目都會繼承的超級POM。這段配置使用idcentral對中央倉庫進行唯一標識，其名稱為MavenRepository Switchboard,它使用default倉庫布局。最后需要注意的是snapshots元素，其子元素enabled的值為false，表示不從該中央倉庫下載快照版本的構件。

4.私服
私服是一種特殊的遠程倉庫，它是架設在局域網內的倉庫服務，私服代理廣域網上的遠程倉庫，供局域網內的Maven用戶使用。當Maven需要下載構件的時候，它從私服請求，如果私服上不存在該構件，則從外部的遠程倉庫下載，緩存在私服上之后，再為Maven的下載請求提供服務。此外，一些無法從外部倉庫下載到的構件也能從本地上傳到私服上供大家使用。

遠程倉庫的配置

在很多情況下，默認的中央倉庫無法滿足項目的需求，可能項目需要的構件存在于另外一個遠程倉庫中，如:JBoss，Maven倉庫。這時，可以在POM中配置該倉庫，見代碼請單：

?

Xml代碼??

1.?<project>??

2.???...??

3.???<repositories>??

4.?????<repository>??

5.???????<id>jboss</id>??

6.???????<name>JBoss?Repository</name>??

7.???????<url>http://repository.jboss.com/maven2/</url>??

8.???????<releases>??

9.?????????<enabled>true</enabled>??

10.??????</releases>??

11.????</repository>??

12.????<snapshots>??

13.??????<enabled>false</enabled>??

14.????</snapshots>??

15.????<layout>default</layout>??

16.??</repositories>??

17.??...??

18.</project>??

在repositories元素下，可以使用repository子元素聲明一個或者多個遠程倉庫。該例中聲明了一個id為jboss，名稱為JBoss Repository的倉庫。任何一個倉庫聲明的id必須是唯一的，尤其需要注意的是，maven自帶的中央倉庫使用的id為central，如果其他的倉庫聲明也使用該id，就會覆蓋中央倉庫的配置。該配置中的url值指向了倉庫的地址，一般來說，該地址都基于http協議，maven用戶都可以在瀏覽器中打開倉庫地址瀏覽構件。

該例配置中的releases和snapshots元素比較重要，它們用來控制Maven對于發布版構件和快照版構件的下載。該例中releases的enabled值為true，表示開啟JBoss倉庫的發布版本下載支持，而snapshots的enabled值為false，表示關閉JBoss倉庫的快照版本的下載支持。該例中的layout元素值default表示倉庫的布局是Maven2及Maven3的默認布局，而不是Maven1的布局。

對于releases和snapshots來說，除了enabled，它們還包含另外兩個子元素updatePolicy和checksumPolicy:

?

Xml代碼??

1.?<snapshots>??

2.???<enabled>true</enabled>??

3.???<updatePolicy>daily</updatePolicy>??

4.???<checksumPolicy>ignore</checksumPolicy>??

5.?</snapshots>??

元素updatePolicy用來配置Maven從遠程倉庫檢查更新的頻率，默認的值是daily，表示Maven每天檢查一次。其他可用的值包括：never---從不檢查更新；always---每次構建都檢查更新；interval:X---每隔X分鐘檢查一次更新(X為任意整數)。

元素checksumPolicy用來配置Maven檢查檢驗和文件的策略。當構件被部署到Maven倉庫中時，會同時部署對應的校驗和文件。在下載構件的時候，Maven會驗證校驗和文件，如果校驗和驗證失敗，怎么辦？當checksumPolicy的值為默認的warn時，Maven會在執行構建時輸出警告信息，其他可用的值包括：fail---Maven遇到校驗和錯誤就讓構建失敗；ignore---使用Maven完全忽略校驗和錯誤。

?

1.遠程倉庫的認證

大部分遠程倉庫無須認證就可以訪問，但有時候出于安全方面的考慮，我們需要提認證信息才能訪問一些遠程倉庫。例如，組織內部有一個Maven倉庫服務器，該服務器為每個項目都提供獨立的Maven倉庫，為了防止非法的倉庫訪問，管理員為每個倉庫提供了一組用戶名級密碼。這時，為了能讓Maven訪問倉庫內容，就需要配置認證信息。

配置認證信息和配置倉庫信息不同，倉庫信息可以直接配置在POM文件中，但是認證信息必須配置在settings.xml文件中。這是因為POM往往是被提交到代碼倉庫中供所有成員訪問的，而settings.xml一般只放在本機。因此，settings.xml中配置認證信息更為安全。假設需要為一個id為my-proj的倉庫配置認證信息，編輯settings.xml文件見代碼清單：?

?

Xml代碼??

1.?<settings>??

2.???...??

3.???<servers>??

4.?????<server>??

5.???????<id>my-proj</id>??

6.???????<username>repo-user</username>??

7.???????<password>repo-pwd</password>??

8.?????</server>??

9.???</servers>??

10.??...??

11.</settings>??

Maven使用settings.xml文件中并不顯而易見的servers元素及其server子元素配置倉庫認證信息。上例中，倉庫的認證用戶名為repo-user，認證密碼為repo-pwd。這里的關鍵是id元素，settings.xml中server元素的id必須與POM中需要認證的repository元素的id完全一致。換句話說，正是這個Id將認證信息與倉庫配置聯系在了一起。

?

2.部署至遠程倉庫

私服的一大作用是部署第三方構件，包括組織內部生成的構件以及一些無法從外部倉庫直接獲取的構件。無論是日常開發中生成的構件，還是正式版本發布的構件，都需要部署到倉庫中，供其他團隊成員使用。

Maven除了能對項目進行編譯、測試、打包之外，還能將項目生成的構建部署到倉庫中。首先，需要編輯項目的pom.xml文件。配置distributionManagement元素，見代碼：

Xml代碼??

1.?<project>??

2.???...??

3.???<destributionManagement>??

4.?????<repository>??

5.???????<id>proj-releases</id>??

6.???????<name>Proj?Release?Repository</name>??

7.???????<url>http://192.168.1.100/content/repositories/proj-releases</url>??

8.?????</repository>??

9.?????<snapshotRepository>??

10.??????<id>proj-snapshots</id>??

11.??????<name>Proj?Snapshot?Repository</name>??

12.??????<url>http://192.168.1.100/content/repositories/proj-snapshots</url>??

13.????</snapshotRepository>??

14.??</destributionManagement>??

15.??...??

16.</project>??

distributionManagement包含repository和snapshotRepository子元素，前者表示發布版本構件的倉庫，后者表示快照版本的倉庫。這兩個元素下都需要配置id、name和url，id為該遠程倉庫的唯一標識，name是為了方便人閱讀，關鍵的url表示該倉庫的地址。

往遠程倉庫部署構件的時候，往往需要認證。就是需要在settings.xml中創建一個server元素，其id與倉庫的id匹配，并配置正確的認證信息。不論遠程倉庫下載構件，還是部署構件至遠程倉庫，當需要認證的時候，配置的方式是一樣的。配置正確后，在命令行運行mvn clean deploy，Maven就會將項目構建輸出的構件部署到配置對應的遠程倉庫，如果項目當前的版本是快照版本，則部署到快照版本倉庫地址，否則就部署到發布版本倉庫地址。

快照版本

在Maven的世界中，任何一個項目或者構件都必須有自己的版本。版本的值可能是1.0.0,1.3-alpha-4,2.0,2.1-SNAPSHOT或者2.1-20091214.221414-13。其中，1.0、1.3-alpha-4和2.0是穩定的發布版本，而2.1-SNAPSHOT和2.1-20091214.221414-13是不穩定的快照版本。

Maven為什么要區分發布版本和快照版本呢？簡單的1.0.0、1.2、2.1等不就夠了嗎？為什么還要2.1-SNAPSHOT，甚至是長長的2.1-20091214.221414-13？試想一下這樣的情況，小張在開發模塊A的2.1版本，該版本還未正式發布，與模塊A一同開發的還有模塊B，它由小張的同事季MM開發，B的功能依賴于A。在開發的過程中，小張需要經常將自己最新的構建輸出，交給季MM，供她開發和集成調試，問題是，這個工作如何進行呢？

如果不停更新版本2.1.1、2.1.2、2.1.3....呢？首先，小張和季MM兩人都需要頻繁地更改POM，如果有更多的模塊依賴于模塊A，就會涉及更多的POM更改；其次，大量的版本其實僅僅包含了微小的差異，這樣也會造成為版本號的濫用。

Maven的快照版本機制就是為了解決上述問題。在該例中，小張只需要將模塊A的版本設定為2.1-SNAPSHOT，然后發布到私服中，在發布的過程中，Maven會自動為構件打上時間戳。比如:2.1-20091214.221414-13就表示2009年12月14日?22點14分14秒的第13次快照。有了該時間戳，Maven就能隨時找到倉庫中該構件2.1-SNAPSHOT版本最新的文件。這時，季MM配置對于模塊A的2.1-SNAPSHOT版本的依賴，當她構件模塊B的時候，Maven會自動從倉庫中檢查模塊A的2.1-SNAPSHOT的最新構件，當發現有更新時便進行下載。默認情況下，Maven每天檢查一次更新(由倉庫配置的updatePolicy控制)，用戶也可以使用命令行-U參數強制讓Maven檢查更新，如：mvn clean install-U。

基于快照版本機制，小張在構建成功之后才能將構件部署至倉庫，而季MM可以完全不用考慮模塊A的構建，并且她能確保隨時得到模塊A的最新可用的快照構件，而這一切都不需要額外的手工操作。

從倉庫解析依賴的機制

Maven是根據怎樣的規則從倉庫解析并使用依賴構件的呢？

當本地倉庫沒有依賴構件的時候，Maven會自動從遠程倉庫下載。當依賴版本為快照版本的時候，Maven會自動找到最新的的快照。這背后的依賴解析機制可以概括如下：

1.當依賴的范圍是system的時候，Maven直接從本地文件系統解析構件。

2.根據依賴坐標計算倉庫路徑后，嘗試直接從本地倉庫尋找構件，如果發現相應構件，則解析成功。

3.在本地倉庫不存在相應構件的情況下，如果依賴的版本是顯式的發布版本構件，如：1.2，2.1等，則遍歷所有的遠程倉庫，發現后，下載并解析使用。

4.如果依賴的版本是RELEASE或者LATEST，則基于更新策略讀取所有遠程倉庫的元數據groupId/artifactId/mavenmetadata.xml，將其與本地倉庫的對應元數據合并后，計算出RELEASE或者LATEST真實的值，然后基于這個真實的值檢查本地和遠程倉庫，如步驟1和3。

5.如果依賴的版本是SNAPSHOT，則基于更新策略讀取所有遠程倉庫的元數據groupId/artifactId/version/mavenmetadata.xml，將其與本地倉庫的對應元數據合并后，得到最新快照版本的值，然后基于該值檢查本地倉庫，或者從遠程倉庫下載。

6.如果最后解析得到的構件版本是時間戳格式的快照，如：1.4-20091104.121450-121,則復制其時間戳格式的文件到非時間戳格式，如：SNAPSHOT，并使用該非時間戳格式的構件。

當依賴的版本不明晰的時候，如:RELEASE,LATEST和SNAPSHOT，Maven就需要基于更新遠程倉庫的更新策略來檢查更新。在前面的倉庫配置blog中，有一些配置與此有關；首先是<releases><enabled>和<snapshots><enabled>，只有倉庫開啟了對于發布版本的支持時，才能訪問該倉庫的發布版本構件信息，對于快照版本也是同理；其次要注意的是

<releases>和<snapshots>的子元素<updatePolicy>，該元素配置了檢查更新的頻率。最后，用戶還可以從命令行加入參數-U,強制檢查更新，使用參數后，Maven就會忽略<updatePolicy>的配置。

當Maven檢查完更新策略，并決定檢查依賴更新的時候，就需要檢查倉庫元數據maven-metadata.xml。回顧一下前面提到的RELEASE和LATEST版本，它們分別對應了倉庫中存在的該構件的最新發布版本和最新版本(包含快照)，而這兩個"最新"是基于groupId/artifactId/maven-metadata.xml計算出來的，如：

?

Xml代碼??

1.?<?xml?version="1.0"?encoding="UTF-8"?>??

2.?<metadata>??

3.???<groupId>org.sonatype.nexus</groupId>??

4.???<artifactId>nexus</artifactId>??

5.???<versioning>??

6.?????<latest>1.4.2-SNAPSHOT</latest>??

7.?????<release>1.4.0</release>??

8.?????<versions>??

9.???????<version>1.3.5</version>??

10.??????<version>1.3.6</version>??

11.??????<version>1.4.0-SNAPSHOT</version>??

12.??????<version>1.4.0</version>??

13.??????<version>1.4.0.1-SNAPSHOT</version>??

14.??????<version>1.4.1-SNAPSHOT</version>??

15.??????<version>1.4.2-SNAPSHOT</version>??

16.????</versions>??

17.??</versioning>??

18.</metadata>??

在XML文件列出了倉庫中存在的該構件所有可用的版本，同時latest元素指向了這些版本中最新的那個版本。而release元素指向了這些版本中最新的發布版本。Maven通過合并多個遠程倉庫及本地倉庫的元數據，就能計算出基于所有倉庫的latest和release分別是什么，然后再解析具體的構件。

需要注意的是，在依賴聲明中使用LATEST和RELEASE是不推薦的做法，因為Maven隨時都可能解析到不同的構件，可能今天LATEST是1.3.6,明天就成了1.4.0-SNAPSHOT了，且Maven不會明確告訴用戶這樣的變化。當這種變化造成構建失敗的時候，發現問題變得比較困難。RELEASE因為對應的是最新發布版構建，還相對可靠，LATEST就非常不可靠了，為此，Maven3不再支持在插件配置中使用LATEST和RELEASE。如果不設置插件版本，其效果就和RELEASE一樣，Maven只會解析最新的發布版本構件。不過即使這樣，也還存在潛在的問題。例如，某個依賴的1.1版本與1.2版本可能發布一些接口的變化，從而導致當前Maven構建失敗。

當依賴的版本設為快照版本的時候，Maven也需要檢查更新，這時，Maven會檢查倉庫元數據groupId/artifactId/version/maven-metadata.xml，如例：?

?

Xml代碼??

1.?<?xml?version="1.0"?encoding="UTF-8"?>??

2.?<metadata>??

3.???<groupId>org.sonatype.nexus</groupId>??

4.???<artifactId>nexus</artifactId>??

5.???<version>1.4.2-SNAPSHOT</version>??

6.???<versioning>??

7.?????<snapshot>??

8.???????<timestamp>20091214.221414</timestamp>??

9.???????<buildNumber>13</buildNumber>??

10.????</snapshot>??

11.????<lastUpdated>20091214221558</lastUpdated>??

12.??</versioning>??

13.</metadata>??

該xml文件的snapshot元素包含timestamp和buildNumber兩個子元素，分別代表了這一快照的時間戳和構建號，基于這兩個元素可以得到該倉庫中此快照的最新構件版本實際為1.4.2-20091213.221414-13。通過合并所有遠程倉庫和本地倉庫的元數據，Maven就能知道所有倉庫中該構件的最新快照。?

鏡像

如果倉庫X可以提供倉庫Y存儲的所有內容，那么就可以認為X是Y的一個鏡像。換句話說，任何一個可以從倉庫Y獲得的構件，都胡夠從它的鏡像中獲取。舉個例子，http://maven.net.cn/content/groups/public/是中央倉庫http://repo1.maven.org/maven2/在中國的鏡像，由于地理位置的因素，該鏡像往往能夠提供比中央倉庫更快的務。因此，可以配置Maven使用該鏡像來替代中央倉庫。編輯settings.xml，代碼如下：

?

Xml代碼??

1.?<settings>??

2.???...??

3.???<mirrors>??

4.?????<mirror>??

5.???????<id>maven.net.cn</id>??

6.???????<name>one?of?the?central?mirrors?in?china</name>??

7.???????<url>http://maven.net.cn/content/groups/public/</url>??

8.???????<mirrorOf>central</mirrorOf>??

9.?????</mirror>??

10.??</mirrors>??

11.??...??

12.</settings>??

該例中，<mirrorOf>的值為central，表示該配置為中央倉庫的鏡像，任何對于中央倉庫的請求都會轉至該鏡像，用戶也可以使用同樣的方法配置其他倉庫的鏡像。另外三個元素id,name,url與一般倉庫配置無異，表示該鏡像倉庫的唯一標識符、名稱以及地址。類似地，如果該鏡像需認證，也可以基于該id配置倉庫認證。

關于鏡像的一個更為常見的用法是結合私服。由于私服可以代理任何外部的公共倉庫(包括中央倉庫)，因此，對于組織內部的Maven用戶來說，使用一個私服地址就等于使用了所有需要的外部倉庫，這可以將配置集中到私服，從而簡化Maven本身的配置。在這種情況下，任何需要的構件都可以從私服獲得，私服就是所有倉庫的鏡像。這時，可以配置這樣的一個鏡像，如例：?

?

Xml代碼??

1.?<settings>??

2.???...??

3.???<mirrors>??

4.?????<mirror>??

5.???????<id>internal-repository</id>??

6.???????<name>Internal?Repository?Manager</name>??

7.???????<url>http://192.168.1.100/maven2</url>??

8.???????<mirrorOf>*</mirrorOf>??

9.?????</mirror>??

10.??</mirrors>??

11.??...??

12.</settings>??

該例中<mirrorOf>的值為星號，表示該配置是所有Maven倉庫的鏡像，任何對于遠程倉庫的請求都會被轉至http://192.168.1.100/maven2/。如果該鏡像倉庫需要認證，則配置一個Id為internal-repository的<server>即可。為了滿足一些復雜的需求，Maven還支持更高級的鏡像配置：

1.<mirrorOf>*</mirrorOf>

匹配所有遠程倉庫。

2.<mirrorOf>external:*</mirrorOf>

匹配所有遠程倉庫，使用localhost的除外，使用file://協議的除外。也就是說，匹配所有不在本機上的遠程倉庫。

3.<mirrorOf>repo1,repo2</mirrorOf>

匹配倉庫repo1和repo2，使用逗號分隔多個遠程倉庫。

4.<mirrorOf>*,!repo1</miiroOf>

匹配所有遠程倉庫，repo1除外，使用感嘆號將倉庫從匹配中排除。

需要注意的是，由于鏡像倉庫完全屏蔽了被鏡像倉庫，當鏡像倉庫不穩定或者停止服務的時候，Maven仍將無法訪問被鏡像倉庫，因而將無法下載構件。

倉庫搜索功能

使用Maven進行日常開發的時候，一個常見的問題就是如何尋找需要的依賴，我們可能只知道城垛 要使用類庫的項目名稱，但添加Maven依賴要求提供確切的Maven坐標。這時就可以使用倉庫搜索服務來根據關鍵字得到Maven坐標。下面列了四個倉庫搜索服務：

?

1.Sonatype Nexus

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

?

2.Jarvana

地址：http://www.jarvana.com/jarvana/

?

3.MVNbrowser

地址：http://www.mvnbrowser.com

?

4.MVNrepository

地址：http://mvnrepository.com/

?

總結

以上是生活随笔為你收集整理的maven3实战之仓库的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。