Maven 主模塊和子模塊pom.xml依賴聲明
前言
今天想到了一個(gè)問題,如果一個(gè)依賴只有子模塊用到了,是放入子模塊的 pom.xml 呢,還是放入父模塊的 pom.xml 呢?
理論上當(dāng)然是子模塊單獨(dú)聲明更符合邏輯。但是以上問題的場(chǎng)景來源有兩個(gè):
- 為了方便,或者考慮到其它子模塊或許以后會(huì)用到此依賴的可能性。
- 單模塊項(xiàng)目改造為多模塊后,原本的依賴全部聲明在父模塊 pom.xml 中,考慮是否要大量遷移到用到的子模塊中。
進(jìn)而引申出的問題:
如果依賴全部放入父模塊,部分子模塊沒有用到這些依賴,是否會(huì)增加這些子模塊打包后的代碼體積?
背景知識(shí)
dependencies與dependencyManagement的區(qū)別
- 父項(xiàng)目中的 <dependencies></dependencies> 中定義的所有依賴,在子項(xiàng)目中都會(huì)直接繼承。
- 在父項(xiàng)目中的 <dependencyManagement></dependencyManagement> 中定義的所有依賴,子項(xiàng)目并不會(huì)繼承,我們還要在子項(xiàng)目中引入我們需要的依賴,才能進(jìn)行使用。此時(shí)我們?cè)谧禹?xiàng)目中不用設(shè)置版本。
實(shí)驗(yàn)
為了回答這個(gè)問題:“如果依賴全部放入父模塊,部分子模塊沒有用到這些依賴,是否會(huì)增加這些子模塊打包后的代碼體積?”。我們拿一個(gè) maven 多模塊項(xiàng)目打包測(cè)試一下。
實(shí)驗(yàn)材料:
如圖,一個(gè)多模塊項(xiàng)目。
其中 wx-common 模塊只是放了一些 enums:
父模塊依賴:
<properties> <java.version>11</java.version> <spring-cloud.version>Hoxton.SR8</spring-cloud.version> <wx-common-version>0.0.1-SNAPSHOT</wx-common-version> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <version>2.2.6.RELEASE</version> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> <version>2.2.5.RELEASE</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <version>2.2.6.RELEASE</version> <scope>test</scope> <exclusions> <exclusion> <groupId>org.junit.vintage</groupId> <artifactId>junit-vintage-engine</artifactId> </exclusion> </exclusions> </dependency> <!--lombok--> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <version>1.18.12</version> </dependency> <!-- https://mvnrepository.com/artifact/org.json/json --> <dependency> <groupId>org.json</groupId> <artifactId>json</artifactId> <version>20190722</version> </dependency> <dependency> <groupId>com.jellyfishmix.interchange</groupId> <artifactId>common</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-openfeign</artifactId> <version>2.2.2.RELEASE</version> </dependency> </dependencies> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>${spring-cloud.version}</version> <type>pom</type> <scope>import</scope> </dependency> <dependency> <groupId>com.jellyfishmix.interchange</groupId> <artifactId>wx-common</artifactId> <version>${wx-common-version}</version> <scope>compile</scope> </dependency> </dependencies> </dependencyManagement>
wx-common 模塊無單獨(dú)引入的依賴。
wx-common 模塊單獨(dú)打包后的大?。?982 bytes):
接下來我們把父模塊的依賴都放入 <dependencyManagement></dependencyManagement>
中,這樣子模塊就不會(huì)全部繼承這些依賴,而是需要在子模塊的 pom.xml 中也進(jìn)行聲明,子模塊才能繼承對(duì)應(yīng)的依賴。
按照博主的猜想, 子模塊最初繼承了很多父模塊的依賴,當(dāng)單獨(dú)打包子模塊時(shí),這些依賴被打入了子模塊jar包中。而這些繼承過來的父模塊的依賴中,有很多是子模塊不需要的,因此子模塊單獨(dú)打出的包,會(huì)有不少冗余體積 。
我們把父模塊的依賴都挪入 <dependencyManagement></dependencyManagement>
中,而 子模塊又沒有在自己的 pom.xml 中聲明這些依賴,也就不會(huì)繼承這些依賴,這樣子模塊單獨(dú)打出的包,會(huì)不會(huì)減少很多體積呢 ?
按我們的推測(cè),把父模塊的依賴都放入 <dependencyManagement></dependencyManagement>
中,然后對(duì)子模塊單獨(dú)打包(3982 bytes):
可以看到打包出來的 jar,并沒有按照我們預(yù)先設(shè)想的,體積減少了很多,而是和之前的體積一模一樣(都是3982 bytes)。
看到這個(gè)結(jié)果,博主百思不得其解。難道 子模塊繼承的父模塊的依賴,如果在子模塊中沒有被使用,在子模塊單獨(dú)打包時(shí),就不會(huì)被打入 jar 嗎?
我們?cè)僮鲆粋€(gè)實(shí)驗(yàn)來驗(yàn)證猜想,現(xiàn)在父模塊的依賴還是在 <dependencyManagement></dependencyManagement>
中,需要在子模塊的 pom.xml 中也進(jìn)行聲明,子模塊才能繼承對(duì)應(yīng)的依賴。我們給子模塊的 pom.xml 多聲明幾個(gè)依賴:
<!--lombok--> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <version>1.18.12</version> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> <version>2.2.5.RELEASE</version> </dependency> <!-- https://mvnrepository.com/artifact/org.json/json --> <dependency> <groupId>org.json</groupId> <artifactId>json</artifactId> <version>20190722</version> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-openfeign</artifactId> <version>2.2.2.RELEASE</version> </dependency>
然后對(duì)子模塊單獨(dú)打包(4175 bytes):
可以看到我們的 jar 包體積確實(shí)增加了(4175 - 3982 = 193 bytes),但這些增加的代碼體積,應(yīng)該是我們的 pom.xml 中新增的一對(duì)對(duì) <dependency></dependency>
的體積,而不是真正引入的依賴的代碼。
因此,博主確信了推測(cè): 子模塊繼承的父模塊的依賴/子模塊聲明的依賴,如果在子模塊中沒有被使用,在子模塊單獨(dú)打包時(shí),就不會(huì)被打入 jar 。
進(jìn)一步實(shí)驗(yàn)來確認(rèn)推測(cè),我們?cè)谧幽K中使用一下聲明的依賴。只在子模塊中加兩個(gè)注解: @FeignClient(name = "interchange-wx")
,對(duì)子模塊單獨(dú)打包(4259 bytes):
打包結(jié)果(4259 - 4175 = 84 bytes)。
因此,maven 打包加入的依賴代碼應(yīng)該是被調(diào)用到的部分代碼,沒有被調(diào)用到的依賴代碼不會(huì)被加入打包后的 jar 包中。
實(shí)驗(yàn)結(jié)論
- 子模塊繼承的父模塊的依賴/子模塊聲明的依賴,如果在子模塊中沒有被使用,在子模塊單獨(dú)打包時(shí),就不會(huì)被打入 jar 。
- maven 打包加入的依賴代碼是被調(diào)用到的部分代碼,沒有被調(diào)用到的依賴代碼不會(huì)被加入打包后的 jar 包中。
推薦做法
對(duì)于 “依賴放入子模塊還是父模塊” 這個(gè)問題,推薦將依賴放入父模塊的 <dependencyManagement></dependencyManagement>
中,然后子模塊有需要的依賴,在子模塊的 pom.xml 中聲明。這樣便于在父模塊中統(tǒng)一管理依賴版本,避免子模塊依賴版本不一致造成的混亂或沖突。
到此這篇關(guān)于Maven 主模塊和子模塊pom.xml依賴聲明的文章就介紹到這了,更多相關(guān)Maven pom.xml依賴聲明內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
配置hadoop環(huán)境mapreduce連接不上hdfs解決
這篇文章主要為大家介紹了配置hadoop環(huán)境mapreduce連接不上hdfs解決方法,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-10-10JNI實(shí)現(xiàn)最簡(jiǎn)單的JAVA調(diào)用C/C++代碼
這篇文章主要介紹了JNI實(shí)現(xiàn)最簡(jiǎn)單的JAVA調(diào)用C/C++代碼,具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2017-08-08SpringBoot項(xiàng)目速度提升之延遲初始化(Lazy Initialization)詳解
延遲初始化(Lazy?Initialization)是一種在需要時(shí)才創(chuàng)建或加載對(duì)象的策略,以減少啟動(dòng)時(shí)間和資源消耗,本文就來講講延遲初始化的具體使用吧2023-05-05詳解Java的Hibernate框架中的List映射表與Bag映射
這篇文章主要介紹了Java的Hibernate框架中的List映射表與Bag映射,Hibernate是Java的SSH三大web開發(fā)框架之一,需要的朋友可以參考下2015-12-12springboot 在idea中實(shí)現(xiàn)熱部署的方法
這篇文章主要介紹了springboot 在idea中實(shí)現(xiàn)熱部署的方法,實(shí)現(xiàn)了熱部署,在每一次作了修改之后,都會(huì)自動(dòng)的重啟,非常節(jié)約時(shí)間,感興趣的小伙伴們可以參考一下2018-10-10關(guān)于gradle多模塊項(xiàng)目依賴管理方式
這篇文章主要介紹了關(guān)于gradle多模塊項(xiàng)目依賴管理方式,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2023-04-04