132
技術社區[雲棲]
《maven實戰》讀書筆記4——maven坐標和依賴
maven坐標
maven坐標是什麼
坐標一詞最讓人熟悉的就是讀書時學的x、y軸的橫豎坐標，平麵中由x、y決定一個唯一的點，x、y就是坐標。三維中，x、y、z決定一個唯一的點，x、y、z就是坐標。而在maven中，就是groupId、artifactId、version、packaging等屬性決定一個唯一的項目模塊，這些屬性就是maven項目的坐標。
maven坐標詳解
對於groupId、artifactId、version、packaging，上一篇實際上我已經根據自己的理解說過，但是這本書學到這裏後，卻發現有些地方略有些偏差，因此還需要進行補充和修正。
對於groupId，我說是項目所屬的組，一般可能是公司網址，當時我的理解其實就是公司的網址。
但是讀到這一章，卻發現groupId實際上應該是針對開源項目發布之後的項目網址，而並非是公司網址。隻不過在我之前所接觸的項目中，很多人寫的全是公司網址而已。
究其原因，可能是因為寫的人對maven規範並不是很了解，也或者是公司項目不多，所以也就無所謂怎麼寫。而根據書中所說，maven的規範是不應該都寫公司網址的。
至於artifactId，我之前理解的就是項目名，書學到這裏，個人覺得也還是項目名。不過這個項目名應該更具體的理解為項目裏邊的模塊名，一個模塊其實也就是一個單獨的子項目。
至於version和packaging比較好理解，和之前的沒區別，但了解了一個新的、在我看來不怎麼常用的屬性classifier，這個屬性定義maven項目一些附屬構件，由maven插件決定，不能像前幾個屬性一個樣直接定義值。由於這個屬性我目前不常用，因此隻做了解。
maven依賴
依賴配置
在學習maven一開始就了解到了maven是一個優秀的依賴管理工具，這也是在我看來maven最重要的特性，通常一個比較完整的maven依賴配置是這樣的（下邊的例子隻是為了演示用法，一般不太可能真的從webmvc排除web）：
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>4.0.9.RELEASE</version>
<scope>test</scope>
<type>jar</type>
<optional>true</optional>
<exclusions>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
<version>4.0.9.RELEASE</version>
</exclusion>
</exclusions>
</dependency>
以上配置中前三個屬性就是上邊說的最常用的maven坐標，scope是生效範圍，例如示例中的test，指的是隻有在測試階段有效，也就是運行測試類的測試方法的時候有用。
scope默認值時compile，表示對編譯、測試、運行階段都有效。除開test和compile，還有runtime、system等，我目前基本不怎麼用，也就暫時略過。
type指的是依賴類型，默認是jar，可以理解成jar包，type可以是jar、war和pom等。
optional代表的是可選，值為true代表選擇，值為false為不選擇，這個屬性實際用的也不多。
exclusions、exclusion是排除依賴，例如這裏需要帶入spring-webmvc的jar包，spring-webmvc依賴於spring-web的jar包，也就是說使用maven顯示導入spring-webmvc的jar包時，maven也會把spring-web的jar包也導入進來，如果我們不需要spring-web，就可以在這個地方配置spring-web的坐標排除掉，然後就不會再導入這個依賴包。
依賴傳遞
還是如上邊所示的例子，我們要導入spring-webmvc的jar包，spring-webmvc依賴於spring-web，所以在我們的項目中也會把spring-web的jar包導入進來。
根據上邊對依賴配置的解釋，我們知道配置中有scope，即依賴範圍，如果spring-webmvc中配置的對spring-web的scope是compile，那麼在我們的項目中默認導入進來的spring-web的依賴範圍就也是compile。
但是上邊的結論的前提是我們我們項目中對spring-webmvc的依賴範圍和spring-webmvc中對spring-web的依賴範圍一致。
但這兩個依賴範圍不一致的時候，就需要理解第一直接依賴和第二直接依賴這樣的概念。就比如上述例子中，我們的項目隊spring-webmvc就是第一直接依賴，我們的項目對spring-web就是第二直接依賴。
因此這裏需要特備注意的是，有時候如果有第二直接依賴的包，但沒有生效，可以從這個角度去考慮一下。
還有一個問題就是，針對配置了可選依賴選項的jar，將不會被傳遞，如果需要，必須另外手動導入才行。
依賴調解
maven之所以能根據一定的配置就準確的導入我們需要的依賴，那是因為我們的配置，也就是所說的坐標保證了依賴的唯一性，而一旦出現不唯一的情況，那麼就需要進行選擇，這就涉及到依賴調解，或者就理解成依賴選擇。
之所以會出現這種不唯一的情況，一般都是因為依賴傳遞。
例如我一個項目導入了A.jar和B.jar兩個jar包，而A.jar和B.jar都依賴於C.jar，但是這兩個C.jar的版本version又不一樣，這時候我們的項目就需要選擇究竟是使用哪一個C.jar，這就是所謂的依賴調解。
那麼首先，根據最短路徑原則選擇。
聯係上邊的知識，可以理解成第幾直接依賴的問題。比如剛才A、B、C的例子，由於兩個C.jar都是第二直接依賴，所以他們路徑就是一樣長。假如這裏是A.jar依賴於C-1.jar，而B.jar依賴於D.jar，而D.jar再依賴於C-2.jar，那麼這時候C-1是第二直接依賴，c-2就是第三直接依賴，也就是c-1的路徑比較短，那麼這時候就會選擇c-1而不是c-2。
當然了，上邊是假設B.jar依賴於D.jar，那麼如果就是一開始那樣B.jar就是直接依賴C-2.jar呢，這時候兩個的路徑是一樣的，那就涉及到第一聲明優先原則，也就是說在pom.xml中A和B誰在前，誰就會被選擇，需要注意的是這個原則是maven2.0.9之後才有的。
依賴優化
根據上邊所有的知識，可是知道一個項目的第一、第二乃至第n個直接依賴可能會有若幹個重複的依賴聲明，但是根據一些原則，最終被實際用到的確實唯一的，這些被最終確認的依賴稱為解析依賴，可以通過mvn dependency:list來進行查看，然後可以看到各依賴是第幾依賴，是根據哪個依賴進來的，然後就可以進行一定的優化。
最後更新：2017-11-13 13:03:58