天天看點

Maven進階學習指南

前言

當我們在開發項目時,有時需要用到外部依賴元件,例如當我們需要Json序列化的時候需要用到FastJson元件,我們可以通過下載下傳對應jar包加載到項目中。但當一個大的項目同時需要依賴各種各樣的外部服務,就存在着配置繁瑣、依賴沖突等問題,是以可以通過maven來完成對應的依賴管理功能。

一、Settings配置

settings.xml用來配置maven項目中的各種參數檔案,包括本地倉庫、遠端倉庫、私服、認證等資訊。

1.1 配置概述

1.1.1 全局settings、使用者setting、pom的差別

  • 全局 settings.xml 是 maven 的全局配置檔案,一般位于${maven.home}/conf/settings.xml,即maven檔案夾下的conf中。
  • 使用者 setting是maven的使用者配置檔案,一般位于${user.home}/.m2/settings.xml,即每位使用者都有一份配置檔案。
  • pom.xml 檔案是項目配置檔案,一般位于項目根目錄下或子目錄下。

配置優先級從高到低:pom.xml > 本地 settings > 全局 settings

如果這些檔案同時存在,在應用配置時,會合并它們的内容,如果有重複的配置,優先級高的配置會覆寫優先級低的。

1.1.2 倉庫【重要】

如前言所述,我們依賴的外部服務是需要有地方進行存儲的,而存儲的地方就稱之為倉庫。其中倉庫又分為本地倉庫、中央倉庫、鏡像倉庫、私服。

其對應關系為:

Maven進階學習指南

(1)本地倉庫

當項目在本地編譯或運作時,直接加載本地的依賴服務無疑是最快的。預設情況下,不管在Window還是Linux下,每個使用者在自己使用者目錄下都有一個路徑名為.m2/repository/的倉庫目錄。

而原始的本地倉庫是為空的,是以maven需要知道一個網絡上的倉庫,在本地倉庫不存在時前往下載下傳網絡上的倉庫,也就是遠端倉庫。

(2)中央倉庫

當maven未配置時,會預設請求maven的中央倉庫,中央倉庫包含了這個世界上絕大多數流行的開源java構件,以及源碼、作者資訊、SCM,資訊、許可證資訊等,每個月這裡都會接受全世界java程式員大概1億次的通路,它對全世界java開發者的貢獻由此可見一斑。

但是由于最常見的例如網絡原因等,國外的中央倉庫使用起來并不順利,是以就有了下載下傳位址為國内的中央倉庫,也就是鏡像倉庫。

(3)鏡像倉庫

最常用的鏡像倉庫無疑是阿裡雲的鏡像倉庫(如何配置阿裡雲的鏡像倉庫後面會有講出)。總結來說,鏡像倉庫就是将國外的中心倉庫複制一份到國内,這樣一來下載下傳速度以及通路速度都将很快。

(4)私服

一般來說中央倉庫或者鏡像倉庫都能滿足我們的需求,但是當我們在公司内合作開發代碼時,可能因為系統保密性原因,有一些其他同僚開發的外部依賴隻希望能夠被本公司的人使用,而如果上傳到鏡像倉庫則保密性就不複存在了。是以私服最主要的功能時存儲一些公司内部不希望被公開的依賴服務。

1.2 settings配置詳解

settings.xml配置了本地全局maven的相關配置。

以下是一份seetings.xml的檔案配置頂級元素。

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>
           

1.2.1 localRepository

用來辨別本地倉庫的位置

javascript複制代碼D:/Maven/Repository
           

1.2.2 interactiveMode

maven 是否需要和使用者互動以獲得輸入。預設為true。

arduino複制代碼true
           

1.2.3 usePluginRegistry

maven 是否需要使用 plugin-registry.xml 檔案來管理插件版本。

arduino複制代碼false
           

1.2.4 offline

用來辨別是否以離線模式營運maven。

當系統不能聯網時,可以通過次配置來離線運作。

arduino複制代碼false
           

1.2.5 servers

當使用maven私服時,某些私服需要配置認證資訊,需要在此處填寫相應的配置。之是以不寫在pom.xml中是因為一般項目在上傳至代碼倉庫時同樣會将pom.xml上傳,而setting.xml一般位于使用者本地,是以相對比較安全。

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>
           

1.2.6 mirrors【重要】

用來配置相應的鏡像倉庫。

如果倉庫X可以提供倉庫Y存儲的所有内容,那麼就可以認為X是Y的一個鏡像。用過Maven的都知道,國外的中央倉庫因為網絡原因用起來太慢了,是以選擇一個國内的鏡像就很有必要,我推薦國内的阿裡雲鏡像。 阿裡雲鏡像:配置很簡單,修改conf檔案夾下的settings.xml檔案,添加如下鏡像配置:

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>,因為如果第一個鏡像倉庫配置了如此标志,那麼如果該倉庫即使不存在對應依賴也不會向下遊查詢。

1.2.7 proxies

用來配置代理。

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">
  ...
  <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>
           

1.2.8 profiles【重要】

根據環境參數來調整建構配置的清單。用于定義一組profile

seetings中的profile是 pom.xml 中 profile 元素的裁剪版本。

它包含了id、activation、repositories、pluginRepositories 和 properties 元素。這裡的 profile 元素隻包含這五個子元素是因為這裡隻關心建構系統這個整體(這正是 settings.xml 檔案的角色定位),而非單獨的項目對象模型設定。如果一個 settings.xml 中的 profile 被激活,它的值會覆寫任何其它定義在 pom.xml 中帶有相同 id 的 profile。

(1)repositories

定義了一組遠端倉庫的清單,當該屬性對應的profile被激活時,會使用該遠端倉庫。

xml複制代碼<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>
           

(2)properties

定義了一組拓展屬性,當對應的profile被激活時該屬性有效。

bash複制代碼<!--
  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>
           

(3)id

全局唯一辨別,如果一個 settings.xml 中的 profile 被激活,它的值會覆寫任何其它定義在 pom.xml 中帶有相同 id 的 profile。

(4)pluginRepositories

同repositories差不多,不過該标簽定義的是插件的遠端倉庫。

(5)activation

觸發激活該profile的條件。

xml複制代碼<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>
           

1.2.9 ActiveProfiles

在運作時手工激活的profile。

該元素包含了一組 activeProfile 元素,每個 activeProfile 都含有一個 profile id。任何在 activeProfile 中定義的 profile id,不論環境設定如何,其對應的 profile 都會被激活。如果沒有比對的 profile,則什麼都不會發生。

xml複制代碼<activeProfiles>
    <!-- 要激活的profile id -->
    <activeProfile>env-test</activeProfile>
</activeProfiles>
           

1.2.10 激活profile的三種方式【重要】

上面有提到了兩種激活的profile的方式,還有一種可以通過指令行激活profile。

(1)通過ActiveProfiles激活

如題1.2.9 可以同時激活多個profile。

(2)通過activation結果

如題1.2.8 (5)

(3)通過指令行的方式激活

也是我們經常使用的方式,例如:

css複制代碼mvn -P 
           

我們可以通過在pom.xml或setting.xml中指定不同環境的profile,在編譯建構不同的項目時,通過上述的指令行方式激活對應的profIle。例如在開發環境下:

css複制代碼mvn package -P dev 
           

可以打包開環環境下的項目。

1.3 Q&A

1.3.1 mirrors與repositories的關系【重要】

從上文可以看到,repository标簽與mirror标簽都定義了一個遠端倉庫的位置,那麼當一個依賴同時存在于兩個倉庫時,會先加載那個依賴呢?

這裡需要闡述一下maven加載真正起作用的repository的步驟,

  1. 首先擷取pom.xml中repository的集合,然後擷取setting.xml中mirror中元素。
  2. 如果repository的id和mirror的mirrorOf的值相同,則該mirror替代該repository。
  3. 如果該repository找不到對應的mirror,則使用其本身。
  4. 依此可以得到最終起作用的repository集合。可以了解mirror是複寫了對應id的repository。

mirror相當于一個攔截器,會攔截被mirrorOf比對到的repository,比對原則參照 1.2.6 ,在比對到後,會用mirror裡定義的url替換到repository。

沒有配置mirror

Maven進階學習指南

配置了mirror

Maven進階學習指南

總結來說,當

二、Pom.xml詳解

上章中setting.xml定義了某個環境下全局項目的相關依賴配置,而pom.xml則具體定義了某一個項目中的依賴配置。

2.1 pom元素

2.1.1 基本資訊

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>
           

基本資訊都比較易懂,主要定義了本項目的相關配置說明,例如唯一坐标、版本、項目介紹等。

2.1.2 dependencies【重要】

(1)dependencies

本元素定義了項目中所需要的相關依賴資訊,也是最重要的元素之一。

xml複制代碼<!--該元素描述了項目相關的所有依賴。 這些依賴自動從項目定義的倉庫中下載下傳 -->
<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>
           

(2)如何解決依賴傳遞問題或jar包版本沖突問題

解決上述問題一般有兩種方式:

  • 當我們作為依賴服務提供者時,可以通過<optional>标簽排除掉不想被傳遞的服務。
xml複制代碼<!-- 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的相關版本。

xml複制代碼<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>
           

2.1.3 <dependencyManagement>

當一個服務中存在有多個moudle時,每個子module都可能引用了相同的jar包,但是如果将版本維護到子module的pom中,當需要更新時需要修改所有的pom檔案版本。maven提供了繼承的方式來解決此問題。

xml複制代碼<!--在父pom中定義子pom需要的相關依賴 -->
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.aspectj</groupId>
            <artifactId>aspectjweaver</artifactId>
            <version>1.0.0</version>
        </dependency>
    </dependencies>
</dependencyManagement>
           

在父pom的 <dependencyManagement> 中定義子pom需要的依賴及版本。

xml複制代碼  <!--在子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中查找相關的版本資訊。

2.1.4 properties

properties主要用來定義常量,通過${value}來使用。

xml複制代碼 <!--配置依賴版本-->
 <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

2.1.5 resources

resources标簽用來辨別項目在編譯運作時需要額外編譯的檔案。例如手工引入jar包、不同運作環境對應不同的profile。

xml複制代碼<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>
           

2.1.6 profile

與setting.xml中profile所不同的是(參照1.2.8),pom中的profile有着更多的标簽來描述一組環境。從作用上來區分的話,一般setting.xml用來辨別不同的遠端倉庫,而pom中的profile一般用來辨別目前項目屬于什麼環境,如下是一組常見的pom中的profiles。

xml複制代碼<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不止有指定編譯環境的功能,同樣也可以指定遠端倉庫等其他功能。

2.1.6 modules

當我們項目中有多個子產品時,如果我們要單獨打包的話需要在每一個子產品都執行對應的maven指令,但是通過<modules>标簽可以将子服務或平級服務進行聚合,隻需要打包該服務,也就會将其對應的子子產品同時打包。

xml複制代碼<modules>
    <!-- 引入子子產品所在的相對目錄 -->
    <module>springmybatis</module>
    <!-- 引入同級子產品所在的相對目錄 -->
    <module>../utils</module>
 </modules>
           

2.1.7 plugins

TODO

三、null:jrdp-common:null:jar問題解決

3.1包找不到問題

我們某次在開發功能的時候,在我們的項目中引用了伏羲另外一個系統的jar包,但是預發環境下編譯的時候卻發現建構失敗,原因是

Maven進階學習指南

因為當時項目有用到京東自己的倉庫,是以我們當時第一反應是去倉庫中查找,結果發現倉庫中是有這個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不能未空的時候可以按照此方法進行排查。

作者:京東科技 南韓凱

内容來源:京東雲開發者社

繼續閱讀