在這裡我想陳述一個問題,Maven官方是不主張我們在使用Maven的時候還把項目依賴的一些jar包送出到svn等版本控制系統中進行版本控制。這主要有以下原因:
1) 我們已經使用了Maven來管理我們的依賴jar包,那麼這些jar包就都會儲存在本地倉庫中,我們沒有必要每個項目都儲存一個依賴jar包的拷貝,這會浪費很多的磁盤空間,也違背了Maven設計的初衷。
2) 當我們沒有把依賴的jar包送出到版本控制系統的時候,這也就意味着我們這個項目的容量會相對而言小一些,這給我們帶來的優點就是在我們檢出該項目的時候速度會相對而言更快一些。
3) Jar包一般都不需要進行版本控制,因為它的變化一般不大,我們很少會去更改一個jar包。
有的時候因為安全或者速度的原因,我們不允許直接從網際網路上下載下傳依賴的jar包,這個時候内部的倉庫就出來了。我們可以從這個内部倉庫下載下傳工件,也可以把工件釋出到該倉庫。這個内部倉庫的概念就相當于是公司内部自己管理了一套工件庫,而且可以自由的往這個工件庫裡面釋出公司自己的工件供大家共享。
有的時候可能我們需要把本地的第三方jar包安裝到我們的Maven本地倉庫來建構我們的Maven項目。Maven為我們提供了一個指令可以很輕松的幫我們實作這個功能。
參數file表示需要安裝的第三方jar包在本地的路徑;
參數groupId用于定義該jar包安裝後的groupId;
參數artifactId用于定義該jar包安裝後的artifactId;
參數version用于定義該jar包安裝後的版本;
參數packaging用于定義該jar包安裝後的打包類型。
比如現在我想把我電腦上的“D:\develop\lib\mysql-connector-java-5.1.12-bin.jar”安裝到我的Maven本地倉庫,那麼我就可以在指令視窗運作以下指令來達到這個目的:
mvn install:install-file -Dfile=D:\develop\lib\mysql-connector-5.1.12-bin.jar -DgroupId=mysql -DartifactId=mysql -Dversion=5.1.12 -Dpackaging=jar
之後在其他Maven項目中我們就可以根據定義好的groupId、artifactId、version和packaging類型來添加這裡定義好的mysql-connector-5.1.12-bin.jar的引用了。
前面安裝到本地倉庫的第三方jar包隻能是在本地使用,這樣其他人是無法通路到的。如果需要其他人也能通路到的話,我們就需要把它部署到我們的遠端倉庫上去。我們可以使用以下Maven指令來部署一個第三方jar包到指定的遠端倉庫。
把第三方jar包部署到遠端倉庫的參數和安裝第三方jar包到本地倉庫類似,但它多了兩個參數,一個是repositoryId和url。repositoryId表示需要部署到的遠端倉庫的id,這個遠端倉庫是定義在settings.xml中的;url表示需要部署到的遠端倉庫的url。
預設情況下,使用deploy:deploy-file部署的第三方jar包将會生成一個通用的pom。如果在部署的過程中不需要生成這個pom,我們可以在使用該指令的時候加上參數“-DgeneratePom=false”。
如果我們在使用deploy:deploy-file部署第三方jar到遠端倉庫需要使用一個已有的pom的時候,我們需要在使用該指令的時候加上參數“-DpomFile=<pomFilePath>”。如:
細心的讀者可能已經發現了,我們在使用了參數pomFile的時候沒有指定groupId、artifactId、version和packaging參數。這是因為當我們指定了pomFile的時候這些參數都可以從指定的pom檔案中獲得。
當我們需要部署的是一個源碼jar包的時候,packaging應該指定為java-source,而且generatePom應該指定為false。