2019獨角獸企業(yè)重金招聘Python工程師標準>>>

看著簡單而又復雜的pom.xml文件，看似熟悉，當自己編寫的時候覺得簡單，但是看人家項目的時候又覺得復雜的很，現(xiàn)在我們一起來分析這個pom文件。

Maven的坐標為各種構件引入了秩序，任何一個構件都必須明確的定義自己的坐標，maven的坐標包括如下的元素：

groupId: 定義當前Maven項目隸屬的實際項目

artifactId: 該元素定義實際項目中的一個Maven項目或模塊

version: 該元素定義Maven項目當前所處的版本

packaging: 該元素定義Maven項目的打包方式

classifier: 該元素用來幫助定義構建輸出的一些附屬構件

注：groupId、artifactId、version、packaging是必須定義的，classifier是不能被直接定義的，因為附屬構件不是項目直接默認生成的，而是由附加的插件幫助生成的。

元素詳解：

根元素project下的dependencies元素詳解：

dependencies可以包含一個或者多個dependency元素，以聲明一個或多個項目依賴, 其包含的元素：

groupId、artifactId、version：依賴的基本坐標，對于任何一個依賴來說，基本的坐標是最重要的，Maven是根據(jù)坐標來找到需要的依賴

type: 依賴的類型

scope: 依賴的范圍

optional: 標記依賴是否可選(參見可選性依賴)

exclusions: 用來排除傳遞性依賴(參見依賴的傳遞性)

依賴范圍詳解：

Maven在編譯項目主代碼的時候需要使用一套classpath

Maven在編譯和執(zhí)行測試的時候會使用另外一套classpath

Maven在實際運行項目的時候又會使用一套classpath

依賴范圍就是用來控制依賴與這三種classpath(編譯classpath、測試classpath、運行classpath)的關系

Maven的6種依賴范圍：

compile: 編譯依賴范圍(默認)，對于編譯、測試、運行三種classpath都有效

test: 測試依賴范圍， 只對測試classpath有效。典型范例：Junit

provided: 已提供依賴范圍 對于編譯和測試classpath有效，但在運行時無效。典型范例：servlet-api

runtime: 運行時依賴范圍 對于測試和運行classpath有效，但在對編譯主代碼時無效。典型范例：JDBC

system: 系統(tǒng)依賴范圍

import: (maven2.0.9及以上): 導入依賴范圍，它不會對三種實際的classpath產生影響

依賴范圍(Scope)對于編譯classpath有效對于測試classpath有效對于運行時classpath有效例子

compile	Y	Y	Y	spring-core
test		Y		junit
provided	Y	Y		servlet-api
runtime		Y	Y	JDBC驅動實現(xiàn)
system	Y	Y		本地的，Maven倉庫之外的類庫文件

了解了依賴的基本元素和依賴范圍之后，我們會發(fā)現(xiàn)在我們項目中經常會出現(xiàn)一些默認的配置問題，導致編譯和運行失敗的情況，現(xiàn)在讓我們來學習如何解決這些問題，首先要了解一下依賴的傳遞性

傳遞性依賴和依賴范圍

簡單的說，一般項目中出現(xiàn)問題多數(shù)是因為重復的引用或者引用了較低版本的依賴，或者是他們的依賴范圍發(fā)生了變化。

舉個例子來理解傳遞性依賴：

我們創(chuàng)建了一個Maven Project-----learnDependency，然后我們引入了spring-core這個依賴，然后我們打開spring-core的 pom.xml發(fā)現(xiàn)，spring-core也有自己的依賴：commons-logging，而且該依賴沒有聲明依賴范圍，那么默認的就是 compile，所以這時我們就可以說：commons-logging也是learnDependency的一個依賴，這時我們就將這種依賴稱之為傳遞 性依賴，commons-logging是learnDependency的一個傳遞性依賴。有了傳遞性依賴，我們就可以在使用的時候不去考慮我們引入的 依賴到底是否需要其它依賴，和是否引入多余的依賴，Maven 會解析各個直接依賴的pom，將必要的間接依賴引入到項目中。

細說傳遞性依賴

假設：A依賴于B，B依賴于C，那么我們就說A對于B是第一直接依賴，B對于C是第二直接依賴，A對于C是傳遞性依賴。

因為依賴是有依賴范圍的，那么對于這種傳遞性依賴Maven又是如何界定其依賴范圍的呢？

當?shù)诙苯右蕾嚨姆秶莄ompile的時候，傳遞性依賴的范圍與第一直接依賴的范圍一致；

當?shù)诙苯右蕾嚨姆秶莟est的時候，依賴不會得以傳遞

當?shù)诙苯右蕾嚨姆秶莗rovided的時候，只傳遞第一依賴范圍也為provided的依賴，且傳遞性依賴的范圍同樣是provided；

當?shù)诙苯右蕾嚨姆秶莚untime的時候，傳遞性依賴的范圍與第一直接依賴的范圍一致，但compile除外，此時傳遞性依賴范圍為runtime

?compiletestprovidedruntime

compile	compile			runtime
test	test			test
provided	provided		provided	provided
runtime	runtime			runtime

左側第一列表示第一直接依賴范圍，最上面一行表示第二直接依賴

optional: 有時候我們不想讓依賴傳遞，那么可配置該依賴為可選依賴，將元素optional設置為true即可。

在我們了解了Maven強大的依賴機制之后，我們開始解決問題：

常見問題一：依賴的重復引入

之前說過Maven可以有效的解決依賴的重復引入問題，但是為什么我們在項目還會出現(xiàn)這類問題呢？先讓我們來看一下Maven是如何處理重復引入問題的：

情景一：我們在項目中分別引入了2個依賴A和B，A又依賴的C，C又依賴了D，B也依賴了D，但是這個時候C依賴的D和B依賴的D的版本是不同的：

項目----A---C----D

項目----B---D

也就是說，當前項目引入了2次D依賴，那么這時，Maven將采用第一原則：路徑最近原則

情景二：我們在項目中分別引入了2個依賴A和B，而A和B又都引入了C，但是，此時A依賴的C和B依賴的C版本是不一致的，那么這個時候Maven如何處理呢？

這時，第一原則已經不起作用了，

在Maven2.0.8及之前的版本中 ?和 Maven2.0.9之后的版本Maven對于這種情況的處理方式是不一致的

確切的說：

在Maven2.0.8及之前的版本中Maven究竟會解析哪個版本的依賴，這是不確定的

在Maven2.0.9之后的版本中，制定了第二原則：第一聲明者優(yōu)先

就是說，它取決于在POM中依賴聲明的順序

這個問題就說明了，為什么我們常常遇到的可以正常運行的項目，然后我們增加了一個看似無關的依賴，然后項目就出現(xiàn)了錯誤，就是這個傳遞性依賴搞的鬼！

還要補充說明的一種情況是可選依賴

為什么會有可選依賴呢？是因為某一個項目實現(xiàn)了多個特性，但是我們在面向對象的設計中，有一個原則叫：單一職責性原則，就是強調在一個類只有一項職責，而不是糅合了太多的功能，所以一般這種可選依賴很少會出現(xiàn)。

常見問題二：默認引入的依賴----第二直接依賴的版本過低或者依賴了不穩(wěn)定的快照

這個問題我們在開發(fā)中也經常遇到，在某個第二直接依賴中引入了1.0版本，但是我們現(xiàn)在想使用2.0版本，這時我們要如何解決？

引入一個名詞：排除依賴，也可以叫替換依賴

想實現(xiàn)依賴排除，然后替換成自己想要的依賴，這時我們要用到的一個配置是<exclusions> 和<exclusion>，我們可以使用這一元素聲明排除依賴，然后顯示的聲明我們想要的依賴，在<exclusions>中可 以聲明一個或多個<exclusion>來排除一個或多個傳遞性依賴。

注：聲明<exclusion>的時候只需要聲明groupId和artifactId就能唯一定位依賴圖中的某個依賴。

A -------> ?B ------×----C(version1.0)

|?

|

C(version2.0)

常見問題三：解決重復的配置

我們在開發(fā)中也經常遇到這樣的情況，比如在使用spring framework的時候，他們都是來自于同一個項目的不同模塊，因此這些依賴的版本都是相同的，而且在將來升級的時候，這些版本也會一起被升級，這時 Maven又提供了一種解決方案------使用properties元素定義Maven屬性，然后引用。

示例：

<properties>??<springframework.version>2.5.6</springframework.version>?? </properties>

這個時候我們就可以在聲明依賴的時候使用${springframework.version}來替換具體的版本號

<dependency>??<groupId>org.springframework</groupId>??<artifactId>spring-context-support</artifactId>??<version>${springframework.version}</version>?? </dependency>

如何正確的優(yōu)化依賴

首先我們必須要對maven的依賴處理方式了然于胸，然后我們就可以去除多余的依賴，顯示的聲明必要的依賴，保證每個構件都只有唯一的版本在依賴中存在

使用命令來查看當前項目的已解析依賴：

mvn dependency : list

經過Maven解析之后，就會構成一個依賴樹

也可以使用命令查看當前項目的依賴樹：

mvn dependency : tree

使用命令分析當前當前項目的依賴：

mvn dependency : analyze

該命令執(zhí)行結果的兩個重要部分：

Used undeclared dependencies: 表示項目中使用到的，但是沒有顯示聲明的依賴

Unused declared dependencies: 表示項目中未使用的，但顯示聲明的依賴

注：dependency : analyze只會分析編譯主代碼和測試代碼需要用到的依賴，一些執(zhí)行測試和運行時需要的依賴它無法發(fā)現(xiàn)。

對于項目中的最佳實踐，需要自己多多的嘗試或者看別人的一些分享，這樣對于開發(fā)效率會有很大的幫助，當然在項目開發(fā)的過程中不斷的優(yōu)化和調整這種方法也未嘗不可。

轉載于:https://my.oschina.net/u/2418042/blog/491698

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結

以上是生活随笔為你收集整理的maven详解之坐标与依赖的全部內容，希望文章能夠幫你解決所遇到的問題。

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