Maven學習總結(四)——Maven核心概念
一、Maven坐標
1.1、什麽是坐標?
在平面幾何中坐標(x,y)可以標識平面中唯一的一點。
1.2、Maven坐標主要組成
- groupId:組織標識(包名)
- artifactId:項目名稱
- version:項目的當前版本
- packaging:項目的打包方式,最為常見的jar和war兩種
樣例:
1.3、Maven為什麽使用坐標?
- Maven世界擁有大量構建,我們需要找一個用來唯一標識一個構建的統一規範。
- 擁有了統一規範,就可以把查找工作交給機器。
二、依賴管理
2.1、依賴配置
依賴配置主要包含如下元素:
1 <!--添加依賴配置--> 2 <dependencies> 3 <!--項目要使用到junit的jar包,所以在這裏添加junit的jar包的依賴--> 4 <dependency> 5 <groupId>junit</groupId> 6 <artifactId>junit</artifactId> 7 <version>4.9</version> 8 <scope>test</scope> 9 </dependency> 10 <!--項目要使用到Hello的jar包,所以在這裏添加Hello的jar包的依賴--> 11 <dependency> 12 <groupId>me.gacl.maven</groupId> 13 <artifactId>Hello</artifactId> 14 <version>0.0.1-SNAPSHOT</version> 15 <scope>compile</scope> 16 </dependency> 17 </dependencies>
2.2、依賴範圍
首先需要知道,Maven在編譯項目主代碼的時候需要使用一套classpath. 在執行測試的時候會使用另外一套classpath.實際運行Maven項目的時候,又會使用一套classpath
依賴範圍scope用來控制依賴和編譯,測試,運行的classpath的關系. 主要的是三種依賴關系如下:
1.compile: 默認編譯依賴範圍。對於編譯,測試,運行三種classpath都有效
2.test:測試依賴範圍。只對於測試classpath有效
3.provided:已提供依賴範圍。對於編譯,測試的classpath都有效,但對於運行無效。因為由容器已經提供,例如servlet-api
4.runtime:運行時提供。例如:jdbc驅動
compile (編譯範圍)
compile是默認的範圍;如果沒有提供一個範圍,那該依賴的範圍就是編譯範圍(包括編譯,測試,運行,打包都能用)。編譯範圍依賴在所有的classpath 中可用,同時它們也會被打包。
provided (已提供範圍)
provided 依賴只有在當JDK 或者一個容器已提供該依賴之後才使用(編譯,測試可用)。例如,如果你開發了一個web 應用,你可能在編譯 classpath 中需要可用的Servlet API 來編譯一個servlet,但是你不會想要在打包好的WAR 中包含這個Servlet API;這個Servlet API JAR 由你的應用服務器或者servlet 容器提供。已提供範圍的依賴在編譯classpath (不是運行時)可用。它們不是傳遞性的,也不會被打包。
runtime (運行時範圍)
runtime 依賴在運行和測試系統的時候需要(運行時才可用),但在編譯的時候不需要。比如,你可能在編譯的時候只需要JDBC API JAR,而只有在運行的時候才需要JDBC
驅動實現。
test (測試範圍)
test範圍依賴在一般的編譯和運行時都不需要,它們只有在測試編譯和測試運行階段可用。
system (系統範圍)
system範圍依賴與provided 類似,但是你必須顯式的提供一個對於本地系統中JAR 文件的路徑。這麽做是為了允許基於本地對象編譯,而這些對象是系統類庫的一部分。這樣的構件應該是一直可用的,Maven 也不會在倉庫中去尋找它。如果你將一個依賴範圍設置成系統範圍,你必須同時提供一個systemPath 元素。註意該範圍是不推薦使用的(你應該一直盡量去從公共或定制的 Maven 倉庫中引用依賴)。
最左邊一行表示第一直接依賴範圍,最上面一行表示第二直接依賴範圍,中間的交叉單元格則表示傳遞性依賴範圍。
仔細觀察上面表格,我們發現這樣的規律:
- 當第二直接依賴的範圍是compile的時候,傳遞性依賴的範圍與第一直接依賴的範圍一致;
- 當第二直接依賴的範圍是test的時候,依賴不會得以傳遞;
- 當第二直接依賴的範圍是provided的時候,只傳遞第一直接依賴的範圍也為provided的依賴,切傳遞性依賴的範圍同樣為provided;
- 當第二直接依賴的範圍是runtime的時候,傳遞性依賴的範圍與第一直接依賴的範圍一致,但compile例外,此時傳遞性依賴的範圍為runtime。
2.3、傳遞性依賴
MakeFriends.jar直接依賴於HelloFriends.jar,而HelloFriends.jar又直接依賴於Hello.jar,那麽MakeFriends.jar也依賴於Hello.jar,這就是傳遞性依賴,只不過這種依賴是間接依賴,如下圖所示:
2.4、可選依賴
當project-A 依賴project-B, project-B 依賴project-D時
<dependency>
<groupId>sample.ProjectD</groupId>
<artifactId>ProjectD</artifactId>
<version>1.0-SNAPSHOT</version>
<optional>true</optional>
</dependency>
所以當project-B的依賴的D項目設置<optional>true</optional>時, project-A中如果沒有顯式的引入project-D, 則project-A不依賴project-D, 即project-A可以自己選擇是否依賴project-D
默認<optional>的值為false, 及子項目必須依賴
三、倉庫管理
3.1、Maven倉庫
用來統一存儲所有Maven共享構建的位置就是倉庫
3.2、Maven倉庫布局
根據Maven坐標定義每個構建在倉庫中唯一存儲路徑,大致為:groupId/artifactId/version/artifactId-version.packaging
3.3、倉庫的分類
3.3.1、本地倉庫
每個用戶只有一個本地倉庫,默認是在~/.m2/repository/,~代表的是用戶目錄
3.3.2、遠程倉庫
1、中央倉庫:Maven默認的遠程倉庫,URL地址:http://search.maven.org/
2、私服:是一種特殊的遠程倉庫,它是架設在局域網內的倉庫
四、生命周期
4.1、何為生命周期?
Maven生命周期就是為了對所有的構建過程進行抽象和統一,包括項目清理,初始化,編譯,測試,打包,部署等幾乎所有構建步驟
4.2、Maven三大生命周期
Maven有三套相互獨立的生命周期,請註意這裏說的是"三套",而且"相互獨立",這三套生命周期分別是:
- Clean Lifecycle 在進行真正的構建之前進行一些清理工作。
- Default Lifecycle 構建的核心部分,編譯,測試,打包,部署等等。
- Site Lifecycle 生成項目報告,站點,發布站點。
再次強調一下它們是相互獨立的,你可以僅僅調用clean來清理工作目錄,僅僅調用site來生成站點。當然你也可以直接運行 mvn clean install site 運行所有這三套生命周期。
clean生命周期每套生命周期都由一組階段(Phase)組成,我們平時在命令行輸入的命令總會對應於一個特定的階段。比如,運行mvn clean ,這個的clean是Clean生命周期的一個階段。有Clean生命周期,也有clean階段。Clean生命周期一共包含了三個階段:
- pre-clean 執行一些需要在clean之前完成的工作
- clean 移除所有上一次構建生成的文件
- post-clean 執行一些需要在clean之後立刻完成的工作
"mvn clean" 中的clean就是上面的clean,在一個生命周期中,運行某個階段的時候,它之前的所有階段都會被運行,也就是說,"mvn clean"等同於 mvn pre-clean clean ,如果我們運行 mvn post-clean ,那麽 pre-clean,clean 都會被運行。這是Maven很重要的一個規則,可以大大簡化命令行的輸入。
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的一個插件目標。
Maven生命周期和插件的關系
前面說了,Maven定義了3套相互獨立的生命周期。每套生命周期中都包含著一系列的階段(phase)。這些phase就相當於Maven提供的統一的接口,然後這些phase的實現由Maven的插件來完成。
我們在輸入mvn命令的時候 比如 mvn clean,clean對應的就是Clean生命周期中的clean階段。但是clean的具體操作是由maven-clean-plugin來實現的。
所以說Maven生命周期的每一個階段的具體實現都是由Maven插件實現的。
插件目標(Plugin Goal)
插件能夠為Maven提供不同的功能,而一個插件可能包含多個插件目標(goals),目標可以說是Maven中的最小工作單元。
比如compile:compile 表示執行compile插件的 compile目標。
一個插件通常可以完成多個任務,每一個任務就叫做插件的一個目標。如執行mvn install命令時,調用的插件和執行的插件目標如下:
每個插件都有哪些個目標,官方文檔有更詳細的說明:Maven Plugins
插件的運行
1. 直接調用插件的目標 mvn plugin:goals
例如
mvn compile:compile
mvn clean:clean
2. 綁定到生命周期的phase中
- 首先Maven默認綁定了一些插件到phase中比如
phase | goals |
---|---|
clean | clean:clean |
phase | goals |
---|---|
process-resources | resources:resources |
compile | compiler:compile |
process-test-resources | resources:testResources |
test-compile | compiler:testCompile |
test | surefire:test |
package | ejb:ejb或ejb3:ejb3或jar:jar或par:par或rar:rar或war:war |
install | install:install |
deploy | deploy:deploy |
在當packaging設置為ejb/ejb3/jar/par/rar/war 其中之一的時候,default lifecycle只有下面phase綁定了goal。
phase | goals |
---|---|
process-resources | resources:resources |
compile | compiler:compile |
process-test-resources | resources:testResources |
test-compile | compiler:testCompile |
test | surefire:test |
package | ejb:ejb或ejb3:ejb3或jar:jar或par:par或rar:rar或war:war |
install | install:install |
deploy | deploy:deploy |
phase | goals |
---|---|
site | site:site |
site-deploy | site:deploy |
- 上面是部分Maven已經默認綁定的目標。
- 在默認情況下,並不是所有的phase都綁定了goal,比如clean這個lifecycle是有三個phase的,但是只有其中的一個名為clean的phase默認綁定了一個clean:clean goal,其它兩個phase默認沒有綁定任何goal。
其他默認的插件目標綁定請參考Maven官方文檔。
- 自定義綁定插件
可以在pom.xml中進行綁定配置
<project>
...
<build>
<plugins>
<plugin>
<!-- groupId artifactId version 是maven的坐標 -->
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.1.1</version>
<executions>
<execution>
<id>attach-sources</id>
<phase>verify</phase>
<goals>
<goal>jar-no-fork</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
...
</project>
以上示例中,聲明了maven-source-plugin(使用groupId、artifactId、version指定)。然後在<executions>元素下指定多個任務<execution>,通過指定多個<execution>,就可以把相同插件的目標綁定到不同的生命周期階段。
<id>指定任務名稱(在一個插件中必須唯一),
<phase>指定到的生命周期階段,
<goal>指定插件目標。
如果沒有指定<phase>,那麽就會綁定到插件默認的生命周期階段上。如果插件沒有默認生命周期階段,那麽插件目標將不會被執行。
通過以上的配置,現在執行mvn verify將看到maven-source-plugin的jar-no-fork目標被執行。
以後在執行mvn package命令打包項目時,在package階段之後會執行源代碼打包,生成如:ehcache-core-2.5.0-sources.jar形式的源碼包。
3. 配置插件
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
maven compile插件默認使用的編譯版本是1.5,可以通過配置修改編譯版本。
也可以對插件的各個目標進行更具體的配置。Configuring Plug-ins
作者:熙熙爸爸
鏈接:https://www.jianshu.com/p/ca4ca8a1cca6
來源:簡書
簡書著作權歸作者所有,任何形式的轉載都請聯系作者獲得授權並註明出處。
Maven學習總結(四)——Maven核心概念