一：依賴范圍

Maven在編譯項目主代碼的時候需要使用一套classpath。其次，在編譯和執行測試的時候會使用另外一套classpath。最后，實際運行Maven項目的時候，又會使用一套classpath。

所謂的依賴范圍就是用來控制依賴與這三種classpath(編譯、測試、運行)的關系，Maven有以下幾種依賴范圍：

compile：編譯依賴范圍。如果沒有指定，默認使用該依賴范圍。使用此依賴范圍時，對于編譯、測試、運行都有效。例如：spring-core，編譯、測試、運行時都需要使用該依賴。

test：測試依賴范圍。只對測試classpath有效。例如：JUnit，它只在編譯測試代碼以及運行測試的時候才需要，編譯和運行classpath時無法使用此依賴。

provided：已提供依賴范圍。對于編譯和測試時有效，但在運行時無效。例如：servlet-api，編譯和測試項目的時候需要該依賴，但運行時，由于容器已經提供，就不需要Maven重復的引入。

runtime：運行時依賴。編譯時無效，對于測試和運行有效。例如：JDBC驅動實現，編譯時只需要JDK提供的JDBC接口，只有在執行測試和運行時才需要實現上述接口的具體JDBC驅動。

system：系統依賴范圍。同provided。使用該依賴時必須通過systemPath元素顯式地指定依賴文件路徑。主要用于依賴本地的、且Maven倉庫之外的類庫文件。例如：

javax.sql

jdbc-stdext

2.5

system

${spath}/lib/test.jar

二：傳遞依賴和依賴范圍

當我們依賴一個a.jar時，如果a.jar依賴b.jar，那么只需要早pom中聲明對a.jar的依賴即可，b.jar會被Maven自動加載進來。

例如：有一個org.springframework:spring-core:2.5.6的依賴，而實際上spring-core也有它自己的依賴，它依賴commons-logging。有了傳遞依賴機制，在使用spring-core時不需要考慮它依賴了什么。Maven會自動解析。

依賴范圍在傳遞依賴時會略有變化

當第二直接依賴的范圍是compile的時候，傳遞性依賴的范圍與第一直接依賴的范圍一致；

當第二直接依賴的范圍是test的時候，依賴不會得以傳遞；

當第二直接依賴的范圍是provided的時候，只傳遞第一直接依賴范圍也為provi的依賴，且范圍為provided；

當第二直接依賴的范圍是runtime的時候，傳遞性的依賴范圍與第一直接依賴的范圍一致，但compile例外，此時傳遞依賴范圍為runtime；

三：依賴調解

原則一：路徑最近者優先。例如：A ->B?->C?->X(1.0) 同時 A?->D?->X(2.0)，很顯然X(2.0)路徑更短，會被解析使用。

原則二：第一聲明者優先。在依賴長度相等情況下，解析在pom中依賴聲明中順序考前的。例如：A ->B?->X(1.0) 同時 A?->D?->X(2.0)。如果B在D之前聲明，那么X(1.0)會被解析。

除以上兩種原則外，還可以手動排除，例如：A ->B?->X(1.0)同時A ->X(2.0)。如果項目A希望加載X(2.0)可做如下聲明，通過元素來顯式排除。

com.xxx.xx

xx-B

2.5

com.xx

project-X

com.xxx.xx

project-x

2.0

四：可選依賴

例如：b.jar是一個持久層工具包，它同時支持Mysql和PostgreSql，A項目依賴b.jar，那么在構建A時需要這兩種數據庫的驅動程序，但在使用的時候知會依賴一種數據庫。A項目的依賴聲明如下：

com.xxx.xx

xx.db

2.5

mysql

mysql-connector-java

5.1.10

true

postgresql

postgresql

8.4-701.jdbc3

true

使用元素表示這兩個為可選依賴，這是依賴不會傳遞到A項目，當A項目需要使用基于MySQL數據庫時，需要顯式聲明對mysql的依賴。

另外：在理想的情況下是不會出現這種情況的，因為在面向對象設計中，有一個單一職責原則，即一個jar的職責應該只有一個。所以對于b.jar，最好是創建2個Maven項目，分別實現mysql和postgresql。

五：依賴優化

代碼需要不斷重構才能達到最優，依賴管理也是一樣，需要不斷的進行去除多余依賴，以及顯式的聲明某些必要的依賴。

Maven會自動解析所有項目的直接依賴和傳遞依賴，并根據規則判斷每個依賴的范圍，對于一些依賴沖突也能進行調節，這些工作之后得到這個項目的完整的已解析依賴。

可通過運行以下命令查看當前項目的已解析依賴：

mvn dependency:list

上圖展示了當前項目中所有已解析的依賴，同時每個依賴的范圍也得以明確標示。

如果將直接在pom中聲明的依賴定義為第一層依賴，這些頂層依賴的依賴定義為第二層依賴，則以此類推可以形成一個完整的依賴樹。

可運行以下明細查看當前項目的依賴樹

mvn dependency:tree

從上圖中可以清晰看出，雖然沒有聲明slf4j-api，但它通過傳遞依賴被加載進來，其范圍為compile。

可運行以下命令對當前項目依賴進行簡單分析

上圖中Used undeclared dependencies，表示項目中使用到的，但是沒有顯式聲明的依賴。可以看到第一個依賴是SNAPSHOT版本，它是通過傳遞依賴被加載進來的，這種依賴就是項目中的隱藏的、潛在的炸彈，因為引用的是SNAPSHOT非穩定版本，且不在pom中顯式聲明，很容易被忽略。該炸彈一旦爆炸，往往需要耗費大量時間來查明。

還有一個Unused declared dependencies，表示項目中未使用的，但是顯式聲明的依賴。如果真的不需要，建議去除聲明。但需要注意的是，dependency:analyze知會分析編譯和測試時需要用到的依賴，一些運行時依賴就無法被發現。所以在優化依賴時一定要小心測試。

總結

以上是生活随笔為你收集整理的mysql maven 依赖关系_Maven依赖总结的全部內容，希望文章能夠幫你解決所遇到的問題。

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