一：依賴配置
我們在實際開發匯中最常見的maven依賴如下，讀者可以看到最基本的groupId,artifactId,version等元素組成。
<groupId>...</groupId>
<artifactId>...</artifactId>
<version>..</version>
<type>...</type>
<scope>...<scope>
<optional>...<optional>
<exclusions>
<exclusion>
</exclusion>
</exclusions>
<dependency>
1.groupId、artifactId和version:依賴的基本坐標，對於任何一個依賴來說，基本坐標最重要，Maven根據坐標才能找到需要的依賴。
2.type依賴類型，對於項目坐標定義的packaging。大部分情況下，該元素不必要聲明，其默認值為jar。
3.scope 依賴范圍。我們會在后面詳細介紹。
4.optional:標記依賴是否可選。
5.exclusions:用來排除傳遞性依賴。
在實際應用中只包含最基本的坐標，然而在一些特殊情況下，其他元素至關重要。
二.依賴范圍
依賴范圍就是用來控制依賴與這三種classpath(編譯classpath、測試classpath、運行classpath)的關系，Maven有以下幾種依賴范圍。
1.compile: 編譯依賴范圍。如果沒有指定，就會默認使用該依賴范圍。使用此依賴范圍的maven依賴，對於編譯 測試 運行三種的classpath都有效。
2.test：測試依賴范圍。使用此依賴范圍的Maven依賴，只對於測試的classpath有效，在編譯主代碼或者運行主代碼的時候都無法依賴此類依賴。典型的例子是jUnit,它只有在編譯測試代碼及運行測試代碼的時候才有效。
3.provided:以提供依賴范圍。使用此依賴范圍的maven依賴，對於編譯和測試classpath有效，但在運行時無效。典型的例子是servlet-api，編譯和測試項目的時候需要該依賴，但在運行的時候，由於容器已經提供，就不需要maven重復地引入一遍。打包的時候可以不用包進去，別的設施會提供。事實上該依賴理論上可以參與編譯，測試，運行等周期。相當於compile，但是打包階段做了exclude操作
4.runtime:運行時依賴范圍。使用此依賴范圍的maven依賴，對於測試和運行classpath有效，但在編譯主代碼時無效。典型的例子是JDBC驅動實現，項目主代碼的編譯只需要jdk提供的jdbc的接口，只有在執行測試或者運行測試的時候才需要實現上述接口的jdbc的驅動
5.system:系統依賴范圍。從參與度來說，和provided相同，不過被依賴項不會從maven倉庫下載，而是從本地文件系統拿。需要添加systemPath的屬性來定義路徑，該依賴與三種范圍的classpath
和provided依賴范圍完全一致。可能造成不可移植，謹慎使用。
6.import:導入依賴范圍。該依賴范圍不會對三種classpath產生實際的影響。只有在dependencyManagement下才有效果。
編輯范圍，注意下圖代表例子
3.傳遞性依賴
A依賴B，B依賴C。當前項目為A，只當B在A項目中的scope，那么c在A中的scope是如何得知呢？
當C是test或者provided時，C直接被丟棄，A不依賴C；（排除傳遞依賴）
否則A依賴C，C的scope繼承與B的scope。maven會解析各個依賴的pom，將那些必要的間接依賴，一傳遞性依賴的形式引入到當前的項目中。
3.傳遞性依賴范圍
假設A依賴於B,B依賴於C,我們說A對於B是第一直接依賴，B對於C第二直接依賴，A對於C的傳遞性依賴。
4.依賴調解
針對於傳遞性依賴造成問題的時候，我們需要清楚知道傳遞性依賴的從哪條路徑引入的。例如A->B-C->X(1.0) A->D
->X(2.0),兩條路徑有兩個版本的X，兩個版本都被解析是不對的，因為會造成依賴重復，因此必須選擇一個。maven依賴調解(Dependency Mediation)第一條原則是:路徑最近者優先。因此X(2.0)會被解析使用。當路徑相同時我們采取第二條准則，第一聲明者優先。即誰在pom文件中先聲明，先被解析。
5.排除依賴
exclusions 可以包含一個多個exclusion元素，可以排除一個或多個項目。