彻底理解maven
前言
最近解決jar包沖突問題時,很頭疼,發(fā)現(xiàn)自己對maven的理解太膚淺了,很多細(xì)節(jié)都一知半解,于是最近又學(xué)習(xí)了一把maven,總結(jié)如下:
基本概念
maven有兩個最基本的概念: pom和lifecycle, 這里的pom不是maven構(gòu)建過程中使用的pom文件,但他們之間有聯(lián)系。 pom全稱為Project Object Model, 簡單說就是要對構(gòu)建的項目進(jìn)行建模,將要構(gòu)建的項目看成是一個對象Object,既然是一個對象,這個對象有哪些屬性呢? 在maven中一個項目使用唯一的坐標(biāo)來表示,它包括groupId, artifactId, version, classifier, type(也叫packaging)這五部分,另外一個方面,一個項目肯定不是孤立存在的,可能會依賴其他項目,也就是說這個對象應(yīng)該還有dependencies屬性,用PO表示構(gòu)建對象,使用java代碼描述這個對象的話:
xml具有很強(qiáng)的表達(dá)能力,一個java對象可以用xml來描述,用xml表達(dá)上面這個java對象可以為:
<PO><groupId></groupId><artifactId></artifactId><version></version><classifier><classifier><type></type><dependencies><PO></PO><PO></PO>...</dependencies> </PO>這個是不是和pom.xml很類似? 其實(shí)pom.xml就是PO對象的xml描述,上面這個PO定義還不完整,我們知道在java中類是可以繼承的,PO也有繼承關(guān)系,PO對象存在父類父類對象,用parent表示,它會繼承父類對象的所有屬性。 另一方面,一個項目可能根據(jù)不同職責(zé)分為多個模塊(module),所有模塊其實(shí)也就是一個單獨(dú)的項目,只不過這些項目會使用其父對象的一些屬性來進(jìn)行構(gòu)建。我們將這些新的屬性加到PO的定義中去:
class PO{private String groupId;private String artifactId;private String version;private String classifier;private String type;private Set<PO> dependencies;private PO parent;private Set<PO> modules; }再將這個定義用XML語言表示一下:
<PO><parent></parent><groupId></groupId><artifactId></artifactId><version></version><classifier><classifier><type></type><dependencies><PO></PO><PO></PO>...</dependencies><modules>...</modules> </PO>是不是更像pom.xml了? pom.xml其實(shí)就是對PO對象的xml描述!!
構(gòu)建
項目的構(gòu)建過程對應(yīng)的是PO對象的build屬性,對應(yīng)pom.xml中也就是<build>元素中的內(nèi)容,這里就有引入maven中第二個核心概念:Lifecycle。Lifecycle直譯過來就是生命周期。我們平常會接觸到哪些周期呢?一年中春夏秋冬就是一個周期。一個周期中可能分為多個階段,比如這里的春夏秋冬。在maven中一個構(gòu)建過程就對應(yīng)一個Lifecycle,這個Lifecycle也分為多個階段,每個階段叫做phase。你可能會問,那這個Lifecycle中包含多少個phase呢?一個標(biāo)準(zhǔn)的構(gòu)建Lifecycle包含了如下的phase:
在maven中,你執(zhí)行任何一個phase時,maven會將其之前的phase都執(zhí)行。例如 mvn install,那么maven會將deploy之外的所有phase按照他們出現(xiàn)的順序一次執(zhí)行。
Lifecycle還牽涉到另外一個非常重要的概念:goal。注意上面Lifecycle的定義,也就是說maven為程序的構(gòu)建定義了一套規(guī)范流程:第一步需要validate,第二步需要initialize... ... compile,test,package,... ... install,deploy,但是并沒有定義每一個phase具體應(yīng)該如何操作。這里的phase的作用有點(diǎn)類似于Java語言中的接口,只協(xié)商了一個契約,但并沒有定義具體的動作。比如說compile這個phase定義了在構(gòu)建流程中需要經(jīng)過編譯這個階段,但沒有定義應(yīng)該怎么編譯(編譯的輸入是什么?用什么編譯javac/gcc?)。這里具體的動作就是由goal來定義,一個goal在maven中就是一個Mojo(Maven old java object)。Mojo抽象類中定義了一個execute()方法,一個goal的具體動作就是在execute()方法中實(shí)現(xiàn)。實(shí)現(xiàn)的Mojo類應(yīng)該放在哪里呢?答案是maven plugin里,所謂的plugin其實(shí)也就是一個maven項目,只不過這個項目會引用maven的一些API,plugin項目也具備maven坐標(biāo)。
在執(zhí)行具體的構(gòu)建時,我們需要為lifecycle的每個phase都綁定一個goal,這樣才能夠在每個步驟執(zhí)行一些具體的動作。比如在lifecycle中有個compile phase規(guī)定了構(gòu)建的流程需要經(jīng)過編譯這個步驟,而maven-compile-plugin這個plugin有個compile goal就是用javac來將源文件編譯為class文件的,我們需要做的就是將compile這個phase和maven-compile-plugin中的compile這個goal進(jìn)行綁定,這樣就可以實(shí)現(xiàn)Java源代碼的編譯了。那么有人就會問,在哪里綁定呢?答案是在pom.xml<build>元素中配置即可。例如:
就將maven-myquery-plugin中的query這個goal綁定到了test這個phase,后續(xù)在maven執(zhí)行到test phase時就會執(zhí)行query goal。還有有人可能會問,我都沒有指定Java源文件的位置,編譯啥?這就引出了maven的design principle。在maven中,有一個非常著名的principle就是convention over configuration(約定優(yōu)于配置)。這一點(diǎn)和ant有非常大的區(qū)別,例如使用ant來進(jìn)行編譯時,我們需要指定源文件的位置,輸出文件的位置,javac的位置,classpath... ...在maven中這些都是不需要,若沒有手動配置,maven默認(rèn)從<項目根目錄>/src/main/java這個目錄去查找Java源文件,編譯后的class文件會保存在<項目根目錄>/target/classes目錄。在maven中,所有的PO都有一個根對象,就是Super POM。Super POM中定義了所有的默認(rèn)的配置項,Super POM對應(yīng)的pom.xml文件可以在maven安裝目錄下lib/maven-model-builder-3.0.3.jar:org/apache/maven/model/pom-4.0.0.xml中找到。用一張圖來表示maven Lifecycle,phase,goal之間的關(guān)系:
插件
上面我們提到,Maven 將所有項目的構(gòu)建過程統(tǒng)一抽象成一套生命周期: 項目的清理、初始化、編譯、測試、打包、集成測試、驗證、部署和站點(diǎn)生成 … 幾乎所有項目的構(gòu)建,都能映射到這一組生命周期上. 但生命周期是抽象的(Maven的生命周期本身是不做任何實(shí)際工作), 任務(wù)執(zhí)行(如編譯源代碼)均交由插件完成. 其中每個構(gòu)建步驟都可以綁定一個或多個插件的目標(biāo),而且Maven為大多數(shù)構(gòu)建步驟都編寫并綁定了默認(rèn)插件.當(dāng)用戶有特殊需要的時候, 也可以配置插件定制構(gòu)建行為, 甚至自己編寫插件.
再說生命周期
Maven 擁有三套相互獨(dú)立的生命周期: clean、default 和 site, 而每個生命周期包含一些phase階段, 階段是有順序的, 并且后面的階段依賴于前面的階段. 而三套生命周期相互之間卻并沒有前后依賴關(guān)系, 即調(diào)用site周期內(nèi)的某個phase階段并不會對clean產(chǎn)生任何影響.
clean
clean生命周期的目的是清理項目:
執(zhí)行如$ mvn clean;
default
default生命周期定義了真正構(gòu)建時所需要執(zhí)行的所有步驟:
執(zhí)行如$ mvn clean install;
site
site生命周期的目的是建立和發(fā)布項目站點(diǎn): Maven能夠基于POM所包含的信息,自動生成一個友好的站點(diǎn),方便團(tuán)隊交流和發(fā)布項目信息
執(zhí)行命令如$ mvn clean deploy site-deploy;
這三個lifecycle定義了其包含的phase。maven會在這三個lifecycle中匹配對應(yīng)的phase。當(dāng)執(zhí)行某個phase時,maven會依次執(zhí)行在這個phase之前的phase。
插件
生命周期的階段phase與插件的目標(biāo)goal相互綁定, 用以完成實(shí)際的構(gòu)建任務(wù). 而對于插件本身, 為了能夠復(fù)用代碼,它往往能夠完成多個任務(wù), 這些功能聚集在一個插件里,每個功能就是一個目標(biāo).
如:$ mvn compiler:compile: 冒號前是插件前綴, 后面是該插件目標(biāo)(即: maven-compiler-plugin的compile目標(biāo)).
而該目標(biāo)綁定了default生命周期的compile階段: 他們的綁定能夠?qū)崿F(xiàn)項目編譯的目的.
內(nèi)置綁定
為了能讓用戶幾乎不用任何配置就能使用Maven構(gòu)建項目, Maven 默認(rèn)為一些核心的生命周期綁定了插件目標(biāo), 當(dāng)用戶通過命令調(diào)用生命周期階段時, 對應(yīng)的插件目標(biāo)就會執(zhí)行相應(yīng)的邏輯.
上圖只列出了打包方式為jar且擁有插件綁定關(guān)系的階段(packaging 定義了Maven項目打包方式, 通常打包方式與所生成構(gòu)件擴(kuò)展名對應(yīng),有jar(默認(rèn))、war、pom、maven-plugin等., 其他打包類型生命周期的默認(rèn)綁定關(guān)系可參考: Built-in Lifecycle Bindings、Plugin Bindings for default Lifecycle Reference.
自定義綁定
除了內(nèi)置綁定以外, 用戶還能夠自定義將某個插件目標(biāo)綁定到生命周期的某個階段上. 如創(chuàng)建項目的源碼包, maven-source-plugin插件的jar-no-fork目標(biāo)能夠?qū)㈨椖康闹鞔a打包成jar文件, 可以將其綁定到verify階段上:
executions下每個execution子元素可以用來配置執(zhí)行一個任務(wù).
聚合與繼承
Maven的聚合特性(aggregation)能夠使項目的多個模塊聚合在一起構(gòu)建, 而繼承特性(inheritance)能夠幫助抽取各模塊相同的依賴、插件等配置,在簡化模塊配置的同時, 保持各模塊一致.
模塊聚合
隨著項目越來越復(fù)雜(需要解決的問題越來越多、功能越來越重), 我們更傾向于將一個項目劃分幾個模塊并行開發(fā), 如: 將feedcenter-push項目劃分為client、core和web三個模塊, 而我們又想一次構(gòu)建所有模塊, 而不是針對各模塊分別執(zhí)行$ mvn命令. 于是就有了Maven的模塊聚合 -> 將feedcenter-push作為聚合模塊將其他模塊聚集到一起構(gòu)建:
聚合POM
聚合模塊POM僅僅是幫助聚合其他模塊構(gòu)建的工具, 本身并無實(shí)質(zhì)內(nèi)容:
通過在一個打包方式為pom的Maven項目中聲明任意數(shù)量的module以實(shí)現(xiàn)模塊聚合:
packaging: pom, 否則無法聚合構(gòu)建.
modules: 實(shí)現(xiàn)聚合的核心,module值為被聚合模塊相對于聚合POM的相對路徑, 每個被聚合模塊下還各自包含有pom.xml、src/main/java、src/test/java等內(nèi)容, 離開聚合POM也能夠獨(dú)立構(gòu)建
若<packaging>元素的內(nèi)容是jar,那么我們很好理解,也就是說這個項目最終會被打包成一個jar包,那<packaging>元素為pom又是什么意思呢?從字面上的意思來看,這個項目將打包成一個pom。我們不妨去maven倉庫里去瞧瞧(前提是已經(jīng)在項目下運(yùn)行了mvn install命令)。可以發(fā)現(xiàn)這個文件其實(shí)和項目中的pom.xml是同一個文件,這樣做的目的是什么呢?上面我們說過PO對象也是有繼承關(guān)系的,<packaging>pom</packaging>的作用就在這里,這就是maven中project inheritance的概念。當(dāng)實(shí)際執(zhí)行maven命令的時候,會根據(jù)project inheritance關(guān)系對項目的pom.xml進(jìn)行轉(zhuǎn)化,得到真正執(zhí)行時所用到的pom.xml,即所謂的effective pom,因此可以得到一個結(jié)論:所有<packaging>元素為pom的項目其實(shí)并不會輸出一個可供外部使用,類似于jar包的東西。這類項目的作用有兩個:
管理子項目
例如這里的api和biz就是echo項目的兩個module。若沒有echo這個父項目,我們需要到api和biz兩個項目下分別執(zhí)行mvn install命令才能完成整個構(gòu)建過程,而有了echo這個父項目之后,我們只需在echo項目中執(zhí)行mvn install即可,maven會解析pom.xml,發(fā)現(xiàn)該項目有api和biz兩個module,它會分別到這兩個項目下去執(zhí)行mvn install命令。當(dāng)module數(shù)量比較多的時候,能大大提高構(gòu)建的效率。
管理繼承屬性
比如A和B都需要某個依賴,那么在父類項目的pom.xml中聲明即可,因為根據(jù)PO對象的繼承關(guān)系,A和B項目會繼承父類項目的依賴,這樣就可以減少一些重復(fù)的輸入。
effective pom包含了當(dāng)前項目的PO對象,直到Super POM對應(yīng)的PO對象中的信息。要看一個項目的effective pom,只需在項目中執(zhí)行
mvn help:effective-pom
命令即可查看。這里順帶說一句,有的同學(xué)可能不理解上面這個命令是什么意思。maven命令的語法為
mvn [options] [goal(s)] [phase(s)]
goal和phase。maven允許你執(zhí)行一個或者多個goals/phases。很明顯這面的命令help:effective-pom并不是一個phase,那么也就是說它是一個goal。對這個goal只不過是采用了縮寫的形式,其全稱是這樣的:
以分號為分隔符,包含了groupId,artifactId,version,goal四部分。若groupId為org.apache.maven.plugins則可以使用上述的簡寫形式。也就是說
mvn help:effective-pom mvn org.apache.maven.plugins:maven-help-plugin:2.2:effective-pom是等價的,都是執(zhí)行了maven-help-plugin這個plugin中的effective-pom這個goal。
我們知道一個plugin中可以包含多個goal,goal可以綁定到lifecycle中的某一個phase,這樣在執(zhí)行這個phase的時候就會調(diào)用該goal。那那些沒有綁定到phase上的goal應(yīng)該如何執(zhí)行呢?這就是 mvn [goal(s)]
這里的goal也就是官方文檔中所說的standalone goal,也就是說若一個plugin中的某個goal沒有和一個phase進(jìn)行綁定,可以通過這種方式來執(zhí)行。可能有的讀者使用過
這條命令,這里其實(shí)就是單獨(dú)執(zhí)行一個goal,這個goal的作用是分析該工程的依賴并使用樹狀的形式打印出來。這里的dependency:tree其實(shí)是一個簡寫的形式,其完×××式是:
mvn org.apache.maven.plugins:maven-dependency-plugin:<版本號信息>:tree也就是說單獨(dú)執(zhí)行一個goal的方式是:
mvn <groupId>:<artifactId>:<version>:<goal>
每次都要敲這么長一串命令是很繁瑣的,因此才有了上述的簡寫的形式。maven規(guī)定了對于plugin的artifactId是如下兩種形式:
maven-{prefix}-maven-plugin
的可以使用簡寫的方式${prefix}來表示一個plugin.
模塊繼承
在面向?qū)ο笾? 可以通過類繼承實(shí)現(xiàn)復(fù)用. 在Maven中同樣也可以創(chuàng)建POM的父子結(jié)構(gòu), 通過在父POM中聲明一些配置供子POM繼承來實(shí)現(xiàn)復(fù)用與消除重復(fù)
父pom
與聚合類似, 父POM的打包方式也是pom, 因此可以繼續(xù)復(fù)用聚合模塊的POM(這也是在開發(fā)中常用的方式):
dependencyManagement: 能讓子POM繼承父POM的配置的同時, 又能夠保證子模塊的靈活性: 在父POMdependencyManagement元素配置的依賴聲明不會實(shí)際引入子模塊中, 但能夠約束子模塊dependencies下的依賴的使用(子模塊只需配置groupId與artifactId, 見下).
pluginManagement: 與dependencyManagement類似, 配置的插件不會造成實(shí)際插件的調(diào)用行為, 只有當(dāng)子POM中配置了相關(guān)plugin元素, 才會影響實(shí)際的插件行為.
元素繼承
可以看到, 子POM中并未定義模塊groupId與version, 這是因為子POM默認(rèn)會從父POM繼承了如下元素:
因此所有的springframework都省去了version、junit還省去了scope, 而且插件還省去了executions與configuration配置, 因為完整的聲明已經(jīng)包含在父POM中.
優(yōu)勢: 當(dāng)依賴、插件的版本、配置等信息在父POM中聲明之后, 子模塊在使用時就無須聲明這些信息, 也就不會出現(xiàn)多個子模塊使用的依賴版本不一致的情況, 也就降低了依賴沖突的幾率. 另外如果子模塊不顯式聲明依賴與插件的使用, 即使已經(jīng)在父POM的dependencyManagement、pluginManagement中配置了, 也不會產(chǎn)生實(shí)際的效果.
推薦: 模塊繼承與模塊聚合同時進(jìn)行,這意味著, 你可以為你的所有模塊指定一個父工程, 同時父工程中可以指定其余的Maven模塊作為它的聚合模塊. 但需要遵循以下三條規(guī)則:
在所有子POM中指定它們的父POM;
將父POM的packaging值設(shè)為pom;
在父POM中指定子模塊/子POM的目錄.
parent元素內(nèi)還包含一個relativePath元素, 用于指定父POM的相對路徑, 默認(rèn)../pom.xml
超級pom-約定優(yōu)先于配置
任何一個Maven項目都隱式地繼承自超級POM, 因此超級POM的大量配置都會被所有的Maven項目繼承, 這些配置也成為了Maven所提倡的約定.
Maven Plugin 開發(fā)
詳細(xì)代碼在maven plugin demo
創(chuàng)建plugin項目
mvn archetype:generate -DgroupId=com.fq.plugins -DartifactId=lc-maven-plugin -Dversion=0.0.1-SNAPSHOT-DarchetypeArtifactId=maven-archetype-plugin -DinteractiveMode=false -DarchetypeCatalog=internal使用maven-archetype-plugin Archetype可以快速創(chuàng)建一個Maven插件項目。
pom.xml
插件本身也是Maven項目, 特殊之處在于packaging方式為maven-plugin:
maven-plugin 打包方式能控制Maven為其在生命周期階段綁定插件處理的相關(guān)目標(biāo).
編寫目標(biāo)Mojo
@Mojo(name = "lc", defaultPhase = LifecyclePhase.VERIFY) public class LCMavenMojo extends AbstractMojo {private static final List<String> DEFAULT_FILES = Arrays.asList("java", "xml", "properties");@Parameter(defaultValue = "${project.basedir}", readonly = true)private File baseDir;@Parameter(defaultValue = "${project.build.sourceDirectory}", readonly = true)private File srcDir;@Parameter(defaultValue = "${project.build.testSourceDirectory}", readonly = true)private File testSrcDir;@Parameter(defaultValue = "${project.build.resources}", readonly = true)private List<Resource> resources;@Parameter(defaultValue = "${project.build.testResources}", readonly = true)private List<Resource> testResources;@Parameter(property = "lc.file.includes")private Set<String> includes = new HashSet<>();private Log logger = getLog();@Overridepublic void execute() throws MojoExecutionException, MojoFailureException {if (includes.isEmpty()) {logger.debug("includes/lc.file.includes is empty!");includes.addAll(DEFAULT_FILES);}logger.info("includes: " + includes);try {long lines = 0;lines += countDir(srcDir);lines += countDir(testSrcDir);for (Resource resource : resources) {lines += countDir(new File(resource.getDirectory()));}for (Resource resource : testResources) {lines += countDir(new File(resource.getDirectory()));}logger.info("total lines: " + lines);} catch (IOException e) {logger.error("error: ", e);throw new MojoFailureException("execute failure: ", e);}}private LineProcessor<Long> lp = new LineProcessor<Long>() {private long line = 0;@Overridepublic boolean processLine(String fileLine) throws IOException {if (!Strings.isNullOrEmpty(fileLine)) {++this.line;}return true;}@Overridepublic Long getResult() {long result = line;this.line = 0;return result;}};private long countDir(File directory) throws IOException {long lines = 0;if (directory.exists()) {Set<File> files = new HashSet<>();collectFiles(files, directory);for (File file : files) {lines += CharStreams.readLines(new FileReader(file), lp);}String path = directory.getAbsolutePath().substring(baseDir.getAbsolutePath().length());logger.info("path: " + path + ", file count: " + files.size() + ", total line: " + lines);logger.info("\t-> files: " + files.toString());}return lines;}private void collectFiles(Set<File> files, File file) {if (file.isFile()) {String fileName = file.getName();int index = fileName.lastIndexOf(".");if (index != -1 && includes.contains(fileName.substring(index + 1))) {files.add(file);}} else {File[] subFiles = file.listFiles();for (int i = 0; subFiles != null && i < subFiles.length; ++i) {collectFiles(files, subFiles[i]);}}} }@Parameter: 配置點(diǎn), 提供Mojo的可配置參數(shù). 大部分Maven插件及其目標(biāo)都是可配置的, 通過配置點(diǎn), 用戶可以自定義插件行為
<plugin><groupId>com.fq.plugins</groupId><artifactId>lc-maven-plugins</artifactId><version>0.0.1-SNAPSHOT</version><executions><execution><id>lc</id><phase>verify</phase><goals><goal>lc</goal></goals><configuration><includes><include>java</include><include>lua</include><include>json</include><include>xml</include><include>properties</include></includes></configuration></execution></executions> </plugin>execute(): 實(shí)際插件功能;
異常: execute()方法可以拋出以下兩種異常:
MojoExecutionException: Maven執(zhí)行目標(biāo)遇到該異常會顯示 BUILD FAILURE 錯誤信息, 表示在運(yùn)行期間發(fā)生了預(yù)期的錯誤;
MojoFailureException: 表示運(yùn)行期間遇到了未預(yù)期的錯誤, 顯示 BUILD ERROR 信息
測試&執(zhí)行
通過mvn clean install將插件安裝到倉庫后, 就可將其配置到實(shí)際Maven項目中, 用于統(tǒng)計項目代碼了:
$ mvn com.fq.plugins:lc-maven-plugins:0.0.1-SNAPSHOT:lc你可能注意到為了調(diào)用該插件的goal,我們需要給出該插件的所有坐標(biāo)信息,包裹groupId, artifactId,version號,你可能之前已經(jīng)執(zhí)行過"mvn eclipase:eclipase"或"mvn idea:idea"這樣簡潔的命令,讓我們也來將自己的插件調(diào)用變簡單一點(diǎn)。要通過簡單別名的方式調(diào)用Maven插件,我們需要做到以下兩點(diǎn):
插件的artifactId應(yīng)該遵循-maven-plugin或maven--plugin命名規(guī)則,對于本文中的插件,我們已經(jīng)遵循了。
需要將插件的groupId放在Maven默認(rèn)的插件搜尋范圍之內(nèi),默認(rèn)情況下Maven只會在org.apache.maven.plugins和org.codehaus.mojo兩個groupId下搜索插件,要讓Maven同時搜索我們自己的groupId,我們需要在~/.m2/settings.xml中加入:
在達(dá)到以上兩點(diǎn)之后,我們便可以通過以下命令來調(diào)用自己的插件了:
mvn lc:lc
要在別的項目中應(yīng)用插件也是簡單的,我們只需要在該項目的pom.xml文件中使用上面<plugin>標(biāo)簽聲明該插件即可。
轉(zhuǎn)載于:https://blog.51cto.com/13981400/2386744
總結(jié)
- 上一篇: nginx访问502 gateway,*
- 下一篇: 比特币的超能力:永恒不变