何為Maven坐標(biāo)
是Maven定義的一組規(guī)則腐螟,世界上任何一個(gè)構(gòu)建都可以使用Maven坐標(biāo)唯一標(biāo)識(shí)愿汰,Maven坐標(biāo)的元素包括groupId,artifactId乐纸,version衬廷,packging,classifier汽绢。只需要提供正確的坐標(biāo)信息吗跋,Maven就能找到對(duì)應(yīng)的構(gòu)建。
坐標(biāo)詳解
坐標(biāo)定義例子:
<groupId>org.sonatype.nexus</groupId>
<artifactId>nexus-indexer</artifactId>
<version>2.0.0</version>
<packaging>jar</packaging>
groupId:定義當(dāng)前Maven項(xiàng)目隸屬于的實(shí)際項(xiàng)目
artifactId:該元素定義實(shí)際項(xiàng)目中的一個(gè)Maven項(xiàng)目(模塊)宁昭,推薦的做法是使用實(shí)際項(xiàng)目名稱作為artifactId的前綴
version:該元素定義Maven項(xiàng)目當(dāng)前所處的版本
packaging:該元素定義Maven項(xiàng)目的打包方式
classifier:該元素用來幫助定義構(gòu)建輸出的一些附屬構(gòu)建
依賴詳解
- type:依賴的類型跌宛,對(duì)應(yīng)于項(xiàng)目坐標(biāo)定義的packaging。大部分情況下久窟,該元素不必聲明秩冈,默認(rèn)值為jar
- 依賴范圍:依賴范圍就是用來控制依賴與這三種classpath(編譯classpath,測試classpath斥扛,運(yùn)行classpath)的關(guān)系入问,Maven有以下幾種依賴范圍:
2.1 compile:編譯測試范圍丹锹。如果沒有指定,就會(huì)默認(rèn)使用該依賴范圍芬失。使用此依賴的Maven依賴楣黍,對(duì)于編譯,測試棱烂,運(yùn)行三種classpath都有效
2.2 test:測試依賴范圍租漂,此依賴只對(duì)測試classpath有效
2.3 provided:已提供依賴范圍,此依賴范圍對(duì)編譯和測試classpath有效
2.4 runtime:運(yùn)行時(shí)依賴范圍颊糜,此依賴對(duì)于測試和運(yùn)行有效
2.5 system:系統(tǒng)依賴范圍哩治,依賴范圍和provided完全一致,但是使用此依賴時(shí)必須通過systemPath元素顯示的指定依賴文件的路徑衬鱼,代碼示例如下:
<dependency>
<groupId>java.sql</groupId>
<artifactId>jdbc-stdext</artifactId>
<version>2.0</version>
<scope>system</scope>
<systemPath>${java.home}/lib/rt.jar</systemPath>
</dependency>
- 傳遞性依賴和依賴范圍
第一直接依賴的范圍和第二直接依賴的范圍決定了傳遞性依賴的范圍业筏。如下表所示,最左邊一列表示第一直接依賴范圍鸟赫,最上面一行表示第二直接依賴范圍蒜胖,中間的交叉單元格則表示傳遞性依賴范圍:
compile | test | provided | runtime | |
---|---|---|---|---|
compile | compile | -- | -- | runtime |
test | test | -- | -- | test |
provided | provided | -- | provided | provided |
runtime | runtime | -- | -- | runtime |
為了幫助理解,舉個(gè)例子:account-email項(xiàng)目有一個(gè)com.icegreen:greenmail:1.3.1b的直接依賴我們說這是第一直接依賴抛蚤,其依賴范圍是test台谢;而greenmail又有一個(gè)javax.mail:mail:1.4的直接依賴,我們說這是第二直接依賴岁经,其依賴范圍為compile朋沮。顯然,javax.mail:mail:1.4是account-email的傳遞性依賴蒿偎,對(duì)照表可以知道朽们,當(dāng)?shù)谝恢苯右蕾嚪秶鸀閠est,第二直接依賴范圍是compile的時(shí)候诉位,傳遞性依賴范圍是test,因此菜枷,javax.mail:mail:1.4是account-email的一個(gè)范圍是test的傳遞性依賴
依賴操作
依賴調(diào)解苍糠,當(dāng)傳遞性依賴造成問題的時(shí)候,我們就需要清楚的知道該傳遞性依賴時(shí)從那條依賴路徑引入的
Maven調(diào)解的兩大原則:
1.1 路徑最近者優(yōu)先
1.2 第一聲明者優(yōu)先啤誊,順序最靠前的那個(gè)依賴優(yōu)勝可選依賴使用<optional>元素表示依賴為可選依賴岳瞭,當(dāng)依賴為可選依賴時(shí),該依賴只對(duì)本項(xiàng)目產(chǎn)生影響蚊锹,如若別的項(xiàng)目依賴本項(xiàng)目瞳筏,不會(huì)依賴本項(xiàng)目的可選依賴。使用可選依賴的原因是某一個(gè)項(xiàng)目實(shí)現(xiàn)了多個(gè)特性牡昆,在面向?qū)ο笤O(shè)計(jì)中姚炕,有個(gè)單一職責(zé)型原則,意指一個(gè)類應(yīng)該只有一項(xiàng)職責(zé),而不是糅合太多的功能
排除依賴
假想情況:當(dāng)前項(xiàng)目有一個(gè)第三方依賴柱宦,而這個(gè)第三方依賴由于某些原因依賴了另外一個(gè)類庫的SNAPSHOP版本些椒,那么這個(gè)SNAPSHOP就會(huì)成為當(dāng)前項(xiàng)目的傳遞性依賴,而SNAPSHOP的不穩(wěn)定性會(huì)直接影響到當(dāng)前項(xiàng)目掸刊,這時(shí)候就需要排除掉該SNAPSHOP免糕,并且在當(dāng)前項(xiàng)目中聲明該類庫的某個(gè)正式的發(fā)布版本
解決方法:代碼中使用exclusions元素聲明排除依賴,exclusions可以包含一個(gè)或者多個(gè)exclusions子元素忧侧,因此可次排除一個(gè)或者多個(gè)傳遞性依賴
代碼示例如下:
<dependency>
<groupId>com.juvenxu.mvnbook</groupId>
<artifactId>project-b</artifactId>
<version>1.0.0</version>
<exclusions>
<exclusion>
<groupId>com.juvenxu.mvnbook</groupId>
<artifactId>project-c</artifactId>
</exclusion>
</exclusions>
</dependency>
- 優(yōu)化依賴
4.1 mvn dependency:list石窑,查看當(dāng)前項(xiàng)目的已解析依賴
4.2 mvn dependency:tree,查看當(dāng)前項(xiàng)目的依賴樹
使用上面兩個(gè)命令可以幫助我們詳細(xì)了解項(xiàng)目中所有依賴的具體信息蚓炬,在此基礎(chǔ)上尼斧,還有dependency:analyze工具可以幫助分析當(dāng)前項(xiàng)目的依賴
注:最好是顯示的聲明任何項(xiàng)目中直接用到的依賴
倉庫的分類
本地倉庫
不管Linux還是Windows上,每個(gè)用戶在自己的目錄下都有一個(gè)路徑名為.m2/respository/的倉庫目錄试吁。以.開頭的文件或目錄默認(rèn)是隱藏的棺棵,可以使用ls-a命令顯示隱藏文件或目錄
有時(shí)候,用戶會(huì)想要自定義本地倉庫目錄地址熄捍,可以編輯文件~/.m2/settings.xml烛恤,設(shè)置localRepository元素的值為想要的倉庫地址
Install插件的install目標(biāo)將項(xiàng)目的構(gòu)建輸出文件安裝到本地倉庫私服
私服是一種特殊的遠(yuǎn)程倉庫,為了節(jié)省寬帶和時(shí)間余耽,應(yīng)該在局域網(wǎng)內(nèi)架設(shè)一個(gè)私有的倉庫服務(wù)器缚柏,用其代理所有外部的遠(yuǎn)程倉庫。內(nèi)部的項(xiàng)目還能部署到私服上供其它項(xiàng)目使用碟贾,一些無法外部倉庫下載到的構(gòu)件也能從本地上傳到私服上供大家使用币喧。
私服主要的作用有: 節(jié)省自己的外網(wǎng)寬帶,加速M(fèi)aven構(gòu)建袱耽,部署第三方構(gòu)建杀餐,提高穩(wěn)定性,增強(qiáng)控制朱巨,降低中央倉庫的負(fù)荷
遠(yuǎn)程倉庫的配置
- 在respository元素下史翘,可以使用respository子元素聲明一個(gè)或者多個(gè)遠(yuǎn)程倉庫
- 對(duì)于releases和snapshots來說,除了enabled冀续,塔門還包含另外兩個(gè)子元素uodatePolicy和checksumPolicy
2.1 updatePolicy:配置Maven從遠(yuǎn)程倉庫檢查更新的頻率
2.2 checksumPolicy:配置Maven檢查檢驗(yàn)和文件的策略
2.3 代碼示例:
<snapshots>
<enabled>true</enabled>
<updatePolicy>daily</updatePolicy>
<checksumPolicy>ignore</checksumPolicy>
</snapshots>
- 遠(yuǎn)程倉庫的認(rèn)證需要在settings.xml中配置用戶名和密碼
<servers>
<server>
<id>my-proj</id>
<username>repo-user</username>
<password>repo-pwd</password>
</server>
</servers>
- 部署至遠(yuǎn)程倉庫琼讽,distributionManagement包含repository和snapshotRepository子元素,前者表示發(fā)布版本構(gòu)建的倉庫洪唐,后者表示快照版本的倉庫钻蹬。id為該遠(yuǎn)程倉庫的唯一標(biāo)識(shí),name是為了方便人閱讀凭需,關(guān)鍵的url表示該倉庫的地址问欠,部署到配置的遠(yuǎn)程倉庫命令是mvn clean deploy
<distributionManagement>
<repository>
<id></id>
<name></name>
<url></url>
</repository>
<snapshotRepository>
<id></id>
<name></name>
<url></url>
</snapshotRepository>
</distributionManagement>
文章僅供參考肝匆,代碼并不是全正確,只需要知道在對(duì)應(yīng)的情況溅潜,可以做對(duì)應(yīng)的處理术唬,代碼是變化的,我相信原理不變