如果A依賴B，B依賴C，那麼A→B和B→C都是直接依賴，而A→C是間接依賴。
依賴的範圍
當一個Maven工程添加了對某個jar包的依賴後，這個被依賴的jar包可以對應下面幾個可選的範圍：
①compile
[1]main目錄下的Java代碼可以訪問這個範圍的依賴
[2]test目錄下的Java代碼可以訪問這個範圍的依賴
[3]部署到Tomcat服務器上運行時要放在WEB-INF的lib目錄下
例如：對Hello的依賴。主程序、測試程序和服務器運行時都需要用到。
②test
[1]main目錄下的Java代碼不能訪問這個範圍的依賴
[2]test目錄下的Java代碼可以訪問這個範圍的依賴
[3]部署到Tomcat服務器上運行時不會放在WEB-INF的lib目錄下
例如：對junit的依賴。僅僅是測試程序部分需要。
③provided
[1]main目錄下的Java代碼可以訪問這個範圍的依賴
[2]test目錄下的Java代碼可以訪問這個範圍的依賴
[3]部署到Tomcat服務器上運行時不會放在WEB-INF的lib目錄下
例如：servlet-api在服務器上運行時，Servlet容器會提供相關API，所以部署的時候不需要。
④runtime[瞭解]
[1]main目錄下的Java代碼不能訪問這個範圍的依賴
[2]test目錄下的Java代碼可以訪問這個範圍的依賴
[3]部署到Tomcat服務器上運行時會放在WEB-INF的lib目錄下
例如：JDBC驅動。只有在測試運行和在服務器運行的時候才決定使用什麼樣的數據庫連接。
⑤其他：import、system等。
各個依賴範圍的作用可以概括爲下圖：
這裏“聲明”的先後順序指的是dependency標籤配置的先後順序。
-
- 依賴的排除
有的時候爲了確保程序正確可以將有可能重複的間接依賴排除。請看如下的例子：
●假設當前工程爲survey_public，直接依賴survey_environment。
●survey_environment依賴commons-logging的1.1.1對於survey_public來說是間接依賴。
●當前工程survey_public直接依賴commons-logging的1.1.2
●加入exclusions配置後可以在依賴survey_environment的時候排除版本爲1.1.1的commons-logging的間接依賴
-
- 依賴的排除
有的時候爲了確保程序正確可以將有可能重複的間接依賴排除。請看如下的例子：
●假設當前工程爲survey_public，直接依賴survey_environment。
●survey_environment依賴commons-logging的1.1.1對於survey_public來說是間接依賴。
●當前工程survey_public直接依賴commons-logging的1.1.2
●加入exclusions配置後可以在依賴survey_environment的時候排除版本爲1.1.1的commons-logging的間接依賴
|
<dependency> <groupId>com.atguigu.maven</groupId> <artifactId>Survey160225_4_Environment</artifactId> <version>0.0.1-SNAPSHOT</version> <!-- 依賴排除 --> <exclusions> <exclusion> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> <version>1.1.2</version> </dependency> |
-
- 統一管理目標jar包的版本
以對Spring的jar包依賴爲例：Spring的每一個版本中都包含spring-core、spring-context等jar包。我們應該導入版本一致的Spring jar包，而不是使用4.0.0的spring-core的同時使用4.1.1的spring-context。
|
<dependency> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> <version>4.0.0.RELEASE</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>4.0.0.RELEASE</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-jdbc</artifactId> <version>4.0.0.RELEASE</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-orm</artifactId> <version>4.0.0.RELEASE</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-web</artifactId> <version>4.0.0.RELEASE</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>4.0.0.RELEASE</version> </dependency> |
問題是如果我們想要將這些jar包的版本統一升級爲4.1.1，是不是要手動一個個修改呢？顯然，我們有統一配置的方式：
|
<properties> <spring.version>4.1.1.RELEASE</spring.version> </properties> |
|
…… |
|
<dependency> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> <version>${spring.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>${spring.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-jdbc</artifactId> <version>${spring.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-orm</artifactId> <version>${spring.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-web</artifactId> <version>${spring.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>${spring.version}</version> </dependency> |
這樣一來，進行版本調整的時候只改一改地方就行了。
●Maven有三套相互獨立的生命週期，分別是：
①Clean Lifecycle在進行真正的構建之前進行一些清理工作。
②Default Lifecycle構建的核心部分，編譯，測試，打包，安裝，部署等等。
③Site Lifecycle生成項目報告，站點，發佈站點。
再次強調一下它們是相互獨立的，你可以僅僅調用clean來清理工作目錄，僅僅調用site來生成站點。當然你也可以直接運行 mvn clean install site 運行所有這三套生命週期。
每套生命週期都由一組階段(Phase)組成，我們平時在命令行輸入的命令總會對應於一個特定的階段。比如，運行mvn clean，這個clean是Clean生命週期的一個階段。有Clean生命週期，也有clean階段。
-
- clean生命週期
Clean生命週期一共包含了三個階段：
①pre-clean 執行一些需要在clean之前完成的工作
②clean 移除所有上一次構建生成的文件
③post-clean 執行一些需要在clean之後立刻完成的工作
-
- Site生命週期
①pre-site 執行一些需要在生成站點文檔之前完成的工作
②site 生成項目的站點文檔
③post-site 執行一些需要在生成站點文檔之後完成的工作，並且爲部署做準備
④site-deploy 將生成的站點文檔部署到特定的服務器上
這裏經常用到的是site階段和site-deploy階段，用以生成和發佈Maven站點，這可是Maven相當強大的功能，Manager比較喜歡，文檔及統計數據自動生成，很好看。
-
- Default生命週期
Default生命週期是Maven生命週期中最重要的一個，絕大部分工作都發生在這個生命週期中。這裏，只解釋一些比較重要和常用的階段：
validate
generate-sources
process-sources
generate-resources
process-resources 複製並處理資源文件，至目標目錄，準備打包。
compile 編譯項目的源代碼。
process-classes
generate-test-sources
process-test-sources
generate-test-resources
process-test-resources 複製並處理資源文件，至目標測試目錄。
test-compile 編譯測試源代碼。
process-test-classes
test 使用合適的單元測試框架運行測試。這些測試代碼不會被打包或部署。
prepare-package
package 接受編譯好的代碼，打包成可發佈的格式，如JAR。
pre-integration-test
integration-test
post-integration-test
verify
install將包安裝至本地倉庫，以讓其它項目依賴。
deploy將最終的包複製到遠程的倉庫，以讓其它開發人員與項目共享或部署到服務器上運行。
-
- 生命週期與自動化構建
運行任何一個階段的時候，它前面的所有階段都會被運行，例如我們運行mvn install 的時候，代碼會被編譯，測試，打包。這就是Maven爲什麼能夠自動執行構建過程的各個環節的原因。此外，Maven的插件機制是完全依賴Maven的生命週期的，因此理解生命週期至關重要。
- 插件和目標
●Maven的核心僅僅定義了抽象的生命週期，具體的任務都是交由插件完成的。
●每個插件都能實現多個功能，每個功能就是一個插件目標。
●Maven的生命週期與插件目標相互綁定，以完成某個具體的構建任務。
例如：compile就是插件maven-compiler-plugin的一個功能；pre-clean是插件maven-clean-plugin的一個目標。