當我們在開發專案時,有時需要用到外部依賴元件,例如當我們需要Json序列化的時候需要用到FastJson元件,我們可以通過下載對應jar包載入到專案中。但當一個大的專案同時需要依賴各種各樣的外部服務,就存在著設定繁瑣、依賴衝突等問題,因此可以通過maven來完成對應的依賴管理功能。
settings.xml用來設定maven專案中的各種引數檔案,包括本地倉庫、遠端倉庫、私服、認證等資訊。
設定優先順序從高到低:pom.xml > 本地 settings > 全域性 settings
如果這些檔案同時存在,在應用設定時,會合並它們的內容,如果有重複的設定,優先順序高的設定會覆蓋優先順序低的。
如前言所述,我們依賴的外部服務是需要有地方進行儲存的,而儲存的地方就稱之為倉庫。其中倉庫又分為本地倉庫、中央倉庫、映象倉庫、私服。
其對應關係為:
當專案在本地編譯或執行時,直接載入原生的依賴服務無疑是最快的。預設情況下,不管在Window還是Linux下,每個使用者在自己使用者目錄下都有一個路徑名為.m2/repository/的倉庫目錄。
而原始的本地倉庫是為空的,因此maven需要知道一個網路上的倉庫,在本地倉庫不存在時前往下載網路上的倉庫,也就是遠端倉庫。
當maven未設定時,會預設請求maven的中央倉庫,中央倉庫包含了這個世界上絕大多數流行的開源java構件,以及原始碼、作者資訊、SCM,資訊、許可證資訊等,每個月這裡都會接受全世界java程式設計師大概1億次的存取,它對全世界java開發者的貢獻由此可見一斑。
但是由於最常見的例如網路原因等,國外的中央倉庫使用起來並不順利,因此就有了下載地址為國內的中央倉庫,也就是映象倉庫。
總結來說,映象倉庫就是將國外的中心倉庫複製一份到國內,這樣一來下載速度以及存取速度都將很快。
一般來說中央倉庫或者映象倉庫都能滿足我們的需求,但是當我們在公司內合作開發程式碼時,可能因為系統保密性原因,有一些其他同事開發的外部依賴只希望能夠被本公司的人使用,而如果上傳到映象倉庫則保密性就不復存在了。因此私服最主要的功能時儲存一些公司內部不希望被公開的依賴服務。
settings.xml設定了本地全域性maven的相關設定。
以下是一份seetings.xml的檔案設定頂級元素。
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
https://maven.apache.org/xsd/settings-1.0.0.xsd">
<localRepository>
<interactiveMode>
<usePluginRegistry>
<offline>
<pluginGroups>
<servers>
<mirrors>
<proxies>
<profiles>
<activeProfiles>
</settings>
用來標識本地倉庫的位置
D:/Maven/Repository
maven 是否需要和使用者互動以獲得輸入。預設為true。
true
maven 是否需要使用 plugin-registry.xml 檔案來管理外掛版本。
false
用來標識是否以離線模式運營maven。
當系統不能聯網時,可以通過次設定來離線執行。
false
當使用maven私服時,某些私服需要設定認證資訊,需要在此處填寫相應的設定。之所以不寫在pom.xml中是因為一般專案在上傳至程式碼倉庫時同樣會將pom.xml上傳,而setting.xml一般位於使用者本地,因此相對比較安全。
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
https://maven.apache.org/xsd/settings-1.0.0.xsd">
...
<!--設定伺服器端的一些設定。一些設定如安全證書不應該和pom.xml一起分發。這種型別的資訊應該存在於構建伺服器上的settings.xml檔案中。 -->
<servers>
<!--伺服器元素包含設定伺服器時需要的資訊 -->
<server>
<!--這是server的id(注意不是使用者登陸的id),該id與distributionManagement中repository元素的id相匹配。 -->
<id>server001</id>
<!--鑑權使用者名稱。鑑權使用者名稱和鑑權密碼錶示伺服器認證所需要的登入名和密碼。 -->
<username>my_login</username>
<!--鑑權密碼 。鑑權使用者名稱和鑑權密碼錶示伺服器認證所需要的登入名和密碼。密碼加密功能已被新增到2.1.0 +。詳情請存取密碼加密頁面 -->
<password>my_password</password>
<!--鑑權時使用的私鑰位置。和前兩個元素類似,私鑰位置和私鑰密碼指定了一個私鑰的路徑(預設是${user.home}/.ssh/id_dsa)以及如果需要的話,一個密語。將來passphrase和password元素可能會被提取到外部,但目前它們必須在settings.xml檔案以純文字的形式宣告。 -->
<privateKey>${usr.home}/.ssh/id_dsa</privateKey>
<!--鑑權時使用的私鑰密碼。 -->
<passphrase>some_passphrase</passphrase>
<!--檔案被建立時的許可權。如果在部署的時候會建立一個倉庫檔案或者目錄,這時候就可以使用許可權(permission)。這兩個元素合法的值是一個三位數位,其對應了unix檔案系統的許可權,如664,或者775。 -->
<filePermissions>664</filePermissions>
<!--目錄被建立時的許可權。 -->
<directoryPermissions>775</directoryPermissions>
</server>
</servers>
...
</settings>
用來設定相應的映象倉庫。
如果倉庫X可以提供倉庫Y儲存的所有內容,那麼就可以認為X是Y的一個映象。用過Maven的都知道,國外的中央倉庫因為網路原因用起來太慢了,所以選擇一個國內的映象就很有必要,我推薦國內的阿里雲映象。 阿里雲映象:設定很簡單,修改conf資料夾下的settings.xml檔案,新增如下映象設定:
<mirrors>
<mirror>
<id>alimaven</id>
<name>aliyun maven</name>
<url>http://maven.aliyun.com/nexus/content/groups/public/</url>
<mirrorOf>central</mirrorOf>
</mirror>
<mirror>
<id>alimaven1</id>
<name>aliyun maven1</name>
<url>http://maven.aliyun.com/nexus/content/groups/public/</url>
<mirrorOf>*</mirrorOf>
</mirror>
</mirrors>
其中id與name用來標識唯一的倉庫,url為映象倉庫地址,mirrorOf用來匹配當請求什麼倉庫依賴時使用該映象。
這裡介紹下<mirrorOf>
設定的各種選項
<mirrorOf>*<mirrorOf>
:匹配所有遠端倉庫。<mirrorOf>external:*<mirrorOf>
:匹配所有遠端倉庫,使用localhost的除外,使用file://協定的除外。也就是說,匹配所有不在本機上的遠端倉庫。<mirrorOf>repo1,repo2<mirrorOf>
:匹配倉庫repo1h和repo2,使用逗號分隔多個遠端倉庫。<mirrorOf>*,!repo1<mirrorOf>
:匹配所有遠端倉庫,repo1除外,使用感嘆號將倉庫從匹配中排除。需要注意的是,由於映象倉庫完全螢幕蔽了被映象倉庫,當映象倉庫不穩定或者停止服務的時候,Maven仍將無法存取被映象倉庫,因而將無法下載構件。
此外, maven 讀取mirror 設定是 從上往下讀取的,因此謹慎設定<mirrorOf>*<mirrorOf>
,因為如果第一個映象倉庫設定了如此標誌,那麼如果該倉庫即使不存在對應依賴也不會向下遊查詢。
用來設定代理。
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
https://maven.apache.org/xsd/settings-1.0.0.xsd">
...
<proxies>
<!--代理元素包含設定代理時需要的資訊 -->
<proxy>
<!--代理的唯一定義符,用來區分不同的代理元素。 -->
<id>myproxy</id>
<!--該代理是否是啟用的那個。true則啟用代理。當我們宣告了一組代理,而某個時候只需要啟用一個代理的時候,該元素就可以派上用處。 -->
<active>true</active>
<!--代理的協定。 協定://主機名:埠,分隔成離散的元素以方便設定。 -->
<protocol>http</protocol>
<!--代理的主機名。協定://主機名:埠,分隔成離散的元素以方便設定。 -->
<host>proxy.somewhere.com</host>
<!--代理的埠。協定://主機名:埠,分隔成離散的元素以方便設定。 -->
<port>8080</port>
<!--代理的使用者名稱,使用者名稱和密碼錶示代理伺服器認證的登入名和密碼。 -->
<username>proxyuser</username>
<!--代理的密碼,使用者名稱和密碼錶示代理伺服器認證的登入名和密碼。 -->
<password>somepassword</password>
<!--不該被代理的主機名列表。該列表的分隔符由代理伺服器指定;例子中使用了豎線分隔符,使用逗號分隔也很常見。 -->
<nonProxyHosts>*.google.com|ibiblio.org</nonProxyHosts>
</proxy>
</proxies>
...
</settings>
根據環境引數來調整構建設定的列表。用於定義一組profile
seetings中的profile
是 pom.xml
中 profile
元素的裁剪版本。
它包含了id
、activation
、repositories
、pluginRepositories
和 properties
元素。這裡的 profile 元素只包含這五個子元素是因為這裡只關心構建系統這個整體(這正是 settings.xml 檔案的角色定位),而非單獨的專案物件模型設定。如果一個 settings.xml
中的 profile
被啟用,它的值會覆蓋任何其它定義在 pom.xml
中帶有相同 id 的 profile
。
定義了一組遠端倉庫的列表,當該屬性對應的profile被啟用時,會使用該遠端倉庫。
<repositories>
<!--包含需要連線到遠端倉庫的資訊 -->
<repository>
<!--遠端倉庫唯一標識 -->
<id>codehausSnapshots</id>
<!--遠端倉庫名稱 -->
<name>Codehaus Snapshots</name>
<!--如何處理遠端倉庫裡釋出版本的下載 -->
<releases>
<!--true或者false表示該倉庫是否為下載某種型別構件(釋出版,快照版)開啟。 -->
<enabled>false</enabled>
<!--該元素指定更新發生的頻率。Maven會比較本地POM和遠端POM的時間戳。這裡的選項是:always(一直),daily(預設,每日),interval:X(這裡X是以分鐘為單位的時間間隔),或者never(從不)。 -->
<updatePolicy>always</updatePolicy>
<!--當Maven驗證構件校驗檔案失敗時該怎麼做-ignore(忽略),fail(失敗),或者warn(警告)。 -->
<checksumPolicy>warn</checksumPolicy>
</releases>
<!--如何處理遠端倉庫裡快照版本的下載。有了releases和snapshots這兩組設定,POM就可以在每個單獨的倉庫中,為每種型別的構件採取不同的策略。例如,可能有人會決定只為開發目的開啟對快照版本下載的支援。參見repositories/repository/releases元素 -->
<snapshots>
<enabled />
<updatePolicy />
<checksumPolicy />
</snapshots>
<!--遠端倉庫URL,按protocol://hostname/path形式 -->
<url>http://snapshots.maven.codehaus.org/maven2</url>
<!--用於定位和排序構件的倉庫佈局型別-可以是default(預設)或者legacy(遺留)。Maven 2為其倉庫提供了一個預設的佈局;然而,Maven 1.x有一種不同的佈局。我們可以使用該元素指定佈局是default(預設)還是legacy(遺留)。 -->
<layout>default</layout>
</repository>
</repositories>
定義了一組拓展屬性,當對應的profile被啟用時該屬性有效。
<!--
1. env.X: 在一個變數前加上"env."的字首,會返回一個shell環境變數。例如,"env.PATH"指代了$path環境變數(在Windows上是%PATH%)。
2. project.x:指代了POM中對應的元素值。例如: <project><version>1.0</version></project>通過${project.version}獲得version的值。
3. settings.x: 指代了settings.xml中對應元素的值。例如:<settings><offline>false</offline></settings>通過 ${settings.offline}獲得offline的值。
4. java System Properties: 所有可通過java.lang.System.getProperties()存取的屬性都能在POM中使用該形式存取,例如 ${java.home}。
5. x: 在<properties/>元素中,或者外部檔案中設定,以${someVar}的形式使用。
-->
<properties>
<user.install>${user.home}/our-project</user.install>
</properties>
全域性唯一標識,如果一個 settings.xml
中的 profile
被啟用,它的值會覆蓋任何其它定義在 pom.xml
中帶有相同 id 的 profile
。
同repositories差不多,不過該標籤定義的是外掛的遠端倉庫。
觸發啟用該profile的條件。
<activation>
<!--profile預設是否啟用的標識 -->
<activeByDefault>false</activeByDefault>
<!--當匹配的jdk被檢測到,profile被啟用。例如,1.4啟用JDK1.4,1.4.0_2,而!1.4啟用所有版本不是以1.4開頭的JDK。 -->
<jdk>1.5</jdk>
<!--當匹配的作業系統屬性被檢測到,profile被啟用。os元素可以定義一些作業系統相關的屬性。 -->
<os>
<!--啟用profile的作業系統的名字 -->
<name>Windows XP</name>
<!--啟用profile的作業系統所屬家族(如 'windows') -->
<family>Windows</family>
<!--啟用profile的作業系統體系結構 -->
<arch>x86</arch>
<!--啟用profile的作業系統版本 -->
<version>5.1.2600</version>
</os>
<!--如果Maven檢測到某一個屬性(其值可以在POM中通過${name}參照),其擁有對應的name = 值,Profile就會被啟用。如果值欄位是空的,那麼存在屬性名稱欄位就會啟用profile,否則按區分大小寫方式匹配屬性值欄位 -->
<property>
<!--啟用profile的屬性的名稱 -->
<name>mavenVersion</name>
<!--啟用profile的屬性的值 -->
<value>2.0.3</value>
</property>
<!--提供一個檔名,通過檢測該檔案的存在或不存在來啟用profile。missing檢查檔案是否存在,如果不存在則啟用profile。另一方面,exists則會檢查檔案是否存在,如果存在則啟用profile。 -->
<file>
<!--如果指定的檔案存在,則啟用profile。 -->
<exists>${basedir}/file2.properties</exists>
<!--如果指定的檔案不存在,則啟用profile。 -->
<missing>${basedir}/file1.properties</missing>
</file>
</activation>
在執行時手工啟用的profile。
該元素包含了一組 activeProfile
元素,每個 activeProfile
都含有一個 profile id。任何在 activeProfile
中定義的 profile id,不論環境設定如何,其對應的 profile
都會被啟用。如果沒有匹配的 profile
,則什麼都不會發生。
<activeProfiles>
<!-- 要啟用的profile id -->
<activeProfile>env-test</activeProfile>
</activeProfiles>
上面有提到了兩種啟用的profile的方式,還有一種可以通過命令列啟用profile。
如題1.2.9
可以同時啟用多個profile。
如題1.2.8 (5)
也是我們經常使用的方式,例如:
mvn -P
我們可以通過在pom.xml或setting.xml中指定不同環境的profile,在編譯構建不同的專案時,通過上述的命令列方式啟用對應的profIle。例如在開發環境下:
mvn package -P dev
可以打包開環環境下的專案。
從上文可以看到,repository標籤與mirror標籤都定義了一個遠端倉庫的位置,那麼當一個依賴同時存在於兩個倉庫時,會先載入那個依賴呢?
這裡需要闡述一下maven載入真正起作用的repository的步驟,
id
和mirror的mirrorOf
的值相同,則該mirror替代該repository。mirror相當於一個攔截器,會攔截被mirrorOf
匹配到的repository,匹配原則參照 1.2.6
,在匹配到後,會用mirror裡定義的url替換到repository。
沒有設定mirror
設定了mirror
上章中setting.xml定義了某個環境下全域性專案的相關依賴設定,而pom.xml則具體定義了某一個專案中的依賴設定。
<project xmlns = "http://maven.apache.org/POM/4.0.0"
xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation = "http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
<!-- 模型版本 一般不用更改 -->
<modelVersion>4.0.0</modelVersion>
<!-- 公司或者組織的唯一標誌,也是打包成jar包路徑的依據 -->
<!-- 例如com.companyname.project-group,maven打包jar包的路徑:/com/companyname/project-group -->
<groupId>com.companyname.project-group</groupId>
<!-- 專案的唯一ID,一個groupId下面可能多個專案,就是靠artifactId來區分的 -->
<artifactId>project</artifactId>
<!-- 專案當前版本,格式為:主版本.次版本.增量版本-限定版本號 -->
<version>1.0</version>
<!--專案產生的構件型別,
jar、war主要用來標識專案打包出的服務是jar包還是war包
pom一般用作多moudle的專案中 頂層的pom用來指定子moudle中需要依賴的版本 詳見2.1.3 -->
<packaging>jar</packaging>
<!--定義了本專案的名稱與example的網址 -->
<name>itoken dependencies</name>
<url>www.funtl.com</url>
</project>
基本資訊都比較易懂,主要定義了本專案的相關設定說明,例如唯一座標、版本、專案介紹等。
本元素定義了專案中所需要的相關依賴資訊,也是最重要的元素之一。
<!--該元素描述了專案相關的所有依賴。 這些依賴自動從專案定義的倉庫中下載 -->
<dependencies>
<dependency>
<!------------------- 依賴座標 ------------------->
<!--依賴專案的座標三元素:groupId + artifactId + version -->
<!--其中三要素的來源就是2.1.1中別人定義好的相關資訊 -->
<groupId>org.apache.maven</groupId>
<artifactId>maven-artifact</artifactId>
<version>3.8.1</version>
<!------------------- 依賴傳遞 ------------------->
<!--依賴排除,即告訴maven只依賴指定的專案,不依賴該專案的這些依賴。此元素主要用於解決版本衝突問題 -->
<exclusions>
<exclusion>
<artifactId>spring-core</artifactId>
<groupId>org.springframework</groupId>
</exclusion>
</exclusions>
<!-- 可選依賴,用於阻斷依賴的傳遞性。如果在專案B中把C依賴宣告為可選,那麼依賴B的專案中無法使用C依賴 -->
<optional>true</optional>
<!------------------- 依賴範圍 ------------------->
<!--依賴範圍。在專案發布過程中,幫助決定哪些構件被包括進來
- compile:預設範圍,適用於所有階段,會隨著專案一起釋出;
- runtime: 在執行時需要使用,如JDBC驅動,適用執行和測試階段,不同於例如fastjson,需要在編譯時使用;
- test: 只在測試時使用,用於編譯和執行測試程式碼,例如junit,不同於junit,在釋出時並不需要;
- optional: 當專案自身被依賴時,標註依賴是否傳遞。用於連續依賴時使用 -->
<scope>test</scope>
</dependency>
</dependencies>
解決上述問題一般有兩種方式:
<optional>
標籤排除掉不想被傳遞的服務。<!-- Project A -->
<project>
...
<dependencies>
<!-- declare the dependency to be set as optional -->
<dependency>
<groupId>sample.ProjectB</groupId>
<artifactId>Project-B</artifactId>
<version>1.0</version>
<optional>true</optional>
</dependency>
</dependencies>
</project>
我們的A服務中參照了外部的依賴B服務,此時有A -> B,在別人參照我們時有C -> A ->B,若此時我們A在提供對外服務時不想讓別人依賴B服務,可以在參照B時新增<optional>
標籤為true
,這樣帶C依賴於A時並不會引入B。如果C在此時想要使用B的相關服務,需要在C的pom中顯示的呼叫B的相關服務。
<exclusions>
來去除掉我們依賴包中所不想依賴的其他服務。如果此時我們的A服務依賴於B服務,B服務依賴於C服務,則有A ->B ->C,因為某種原因例如jar包衝突,我們在A中並不想依賴於C服務的版本,可以在呼叫B服務時去除掉C的相關依賴,然後自己再在A中使用C的相關版本。
<project>
...
<dependencies>
<dependency>
<groupId>sample.ProjectB</groupId>
<artifactId>Project-B</artifactId>
<version>1.0</version>
<exclusions>
<exclusion>
<!-- 排除掉B中C的相關依賴 -->
<groupId>sample.ProjectC</groupId>
<artifactId>Project-C</artifactId>
</exclusion>
</exclusions>
</dependency>
<!-- 自己參照C的相關版本 -->
<dependency>
<groupId>sample.ProjectC</groupId>
<artifactId>Project-C</artifactId>
<version>2.0</version>
</dependency>
</dependencies>
</project>
<dependencyManagement>
當一個服務中存在有多個moudle
時,每個子module
都可能參照了相同的jar包,但是如果將版本維護到子module
的pom中,當需要升級時需要修改所有的pom檔案版本。maven提供了繼承的方式來解決此問題。
<!--在父pom中定義子pom需要的相關依賴 -->
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjweaver</artifactId>
<version>1.0.0</version>
</dependency>
</dependencies>
</dependencyManagement>
在父pom的 <dependencyManagement>
中定義子pom需要的依賴及版本。
<!--在子pom中 如下定義了父pom中相關依賴資訊 -->
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.5.10.RELEASE</version>
<relativePath/>
</parent>
<dependencies>
<dependency>
<!--因為參照了父pom 所以可以不指定版本 maven會自動去父pom中查詢指定版本 此處為1.0.0 -->
<groupId>org.aspectj</groupId>
<artifactId>aspectjweaver</artifactId>
</dependency>
</dependencies>
當我們的pom中有定義父pom的元素後,可以在指定需要的依賴時不指定其版本,maven會幫我們去父pom中查詢相關的版本資訊。
properties主要用來定義常數,通過${value}來使用。
<!--設定依賴版本-->
<properties>
<!-- Environment Settings -->
<java.version>1.8</java.version>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<!-- Spring cloud Settings -->
<spring-cloud.version>Finchley.RELEASE</spring-cloud.version>
<spring-boot-admin.version>2.0.1</spring-boot-admin.version>
<zipkin.version>2.10.1</zipkin.version>
</properties>
<dependencies>
<!--spring cloud-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>${spring-cloud.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<!--zipkin-->
<dependency>
<groupId>io.zipkin.java</groupId>
<artifactId>zipkin</artifactId>
<version>${zipkin.version}</version>
</dependency>
<dependencies>
此外,maven還通過約定大於設定的方式定義了一些常用的屬性。
屬性 | 定義 |
---|---|
${basedir} | 存放pom.xml和所有的子目錄 |
${basedir}/src/main/java | 專案的java原始碼 |
${basedir}/src/main/resources | 專案的資源,比如說property檔案,springmvc.xml |
${basedir}/src/main/webapp/WEB-INF | web應用檔案目錄,web專案的資訊,比如存放web.xml、本地圖片、jsp檢視頁面 |
${basedir}/target | 打包輸出目錄 |
${project.version} | 專案版本 |
${project.groupId} | 專案groupid |
resources
標籤用來標識專案在編譯執行時需要額外編譯的檔案。例如手工引入jar包、不同執行環境對應不同的profile。
<build>
<resources>
<!--首先將預設resources目錄下的所有檔案包括 -->
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
<!--只編譯所有以.fxml結尾的檔案 -->
<includes>
<include>**/*.fxml</include>
</includes>
<!--排除掉所有的yaml檔案 -->
<excludes>
<exclude>**/*.yaml</exclude>
</excludes>
</resource>
<!--將不同環境下對應的不同yaml或properties檔案編譯執行 -->
<resource>
<!--
<directory>src/main/profiles/dev</directory>
<directory>src/main/profiles/beta<directory>
<directory>src/main/profiles/pre</directory>
-->
<directory>src/main/profiles/product</directory>
<filtering>true</filtering>
<includes>
<include>**/*.fxml</include>
</includes>
</resource>
<!--將手工引入的jar包編譯執行 -->
<resource>
<directory>lib</directory>
<targetPath>BOOT-INF/lib/</targetPath>
<includes>
<include>**/*.jar</include>
</includes>
</resource>
</resources>
</build>
與setting.xml中profile所不同的是(參照1.2.8),pom中的profile有著更多的標籤來描述一組環境。從作用上來區分的話,一般setting.xml用來標識不同的遠端倉庫,而pom中的profile一般用來標識當前專案屬於什麼環境,如下是一組常見的pom中的profiles。
<profiles>
<profile>
<id>dev</id>
<!--啟用條件 其中預設為該profile 更多啟用條件可以參考1.2.8 -->
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<!--當此profile被啟用時,會將 project.active 的屬性賦值為dev -->
<properties>
<project.active>dev</project.active>
</properties>
</profile>
<profile>
<id>test</id>
<!--當此profile被啟用時,會將 project.active 的屬性賦值為test -->
<properties>
<project.active>test</project.active>
</properties>
</profile>
</profiles>
<resources>
<resource>
<!--根據不同的環境 project.active 取得不同的值 從而會將不同的環境下的yaml或properties檔案編譯進專案中 達到只需要在編譯時指定環境變數即可 不用每次都要修改組態檔 -->
<directory>src/main/${project.active}</directory>
<filtering>true</filtering>
<includes>
<include>**/*.fxml</include>
</includes>
</resource>
</resources>
此外,一般通過 mvn -P dev/beta/pre/product
命令來啟用不同的環境,也可以通過其他的方式來啟用profile,詳見1.2.10。
當然,pom中的profile不止有指定編譯環境的功能,同樣也可以指定遠端倉庫等其他功能。
當我們專案中有多個模組時,如果我們要單獨打包的話需要在每一個模組都執行對應的maven命令,但是通過<modules>
標籤可以將子服務或平級服務進行聚合,只需要打包該服務,也就會將其對應的子模組同時打包。
<modules>
<!-- 引入子模組所在的相對目錄 -->
<module>springmybatis</module>
<!-- 引入同級模組所在的相對目錄 -->
<module>../utils</module>
</modules>
我們某次在開發功能的時候,在我們的專案中參照了伏羲另外一個系統的jar包,但是預發環境下編譯的時候卻發現構建失敗,原因是
因為當時專案有用到京東自己的倉庫,所以我們當時第一反應是去倉庫中查詢,結果發現倉庫中是有這個jar包的。
在發現並不是最常見的jar包不存在的問題後,我們開始分析報錯原因,發現報錯的 jrdp-common
這個包並不是我們直接參照的,而是在我們參照的jar包中參照的,並且 null:jrdp-common:null:jar
可以推測前面應該是 groupID
與 version
。
假設我們的專案是A專案,參照的專案是B專案,也就是 A->B->jrdp-common
於是我們開啟B專案,檢視B的pom結構。
發現B專案的pom中確實參照了jrdp-common
這個包,但是並沒有指定版本,是因為繼承了 xx-parent
這個包,我們在這個包中確實也找到了指定的版本號,因此就排除了專案中沒有指定groupid與版本號的問題。
這個時候好像就問題就陷入了思路,但是我們注意到,我們之前另一個私服上也是有這個包的,那麼之前的在另一個私服上參照好像是沒有問題的,我們檢視了私服了上的pom檔案,發現也是跟專案一樣的。
然後我們就突然想到,會不會是倉庫中的包有問題,果不其然
沒有指定parent也沒有指定版本號,於是我們修改了這個版本的pom,至此問題解決。
總結:因為我們的系統已經被好多個團隊中轉接手過,因此可能在某些地方踩了不少坑,像這種問題應該就是之前的團隊上傳了一些有問題的jar包,導致依賴不可用,但是因為我們之前一直用的私服是沒有什麼問題的,只到這次用到了倉庫問題才浮現。
另外,此問題並不具有普適性,但是當遇到了groupid不能未空的時候可以按照此方法進行排查。
作者:京東科技 韓國凱
內容來源:京東雲開發者社群