Maven提高篇系列之（一）——多模組 vs 繼承

 

 

這是一個Maven提高篇的系列，包含有以下文章：

  

1. Maven提高篇系列之（一）——多模組 vs 繼承
2. Maven提高篇系列之（二）——配置Plugin到某個Phase（以Selenium整合測試為例）
3. Maven提高篇系列之（三）——使用自己的Repository(Nexus)
4. Maven提高篇系列之（四）——使用Profile
5. Maven提高篇系列之（五）——處理依賴衝突
6. Maven提高篇系列之（六）——編寫自己的Plugin（本系列完）

  

 

 

通常來說，在Maven的多模組工程中，都存在一個pom型別的工程作為根模組，該工程只包含一個pom.xml檔案，在該檔案中以模組（module）的形式宣告它所包含的子模組，即多模組工程。在子模組的pom.xml檔案中，又以parent的形式宣告其所屬的父模組，即繼承。然而，這兩種宣告並不必同時存在，我們將在下文中講到這其中的區別。

 

（一）建立Maven多模組工程

 

多模組的好處是你只需在根模組中執行Maven命令，Maven會分別在各個子模組中執行該命令，執行順序通過Maven的Reactor機制決定。先來看建立Maven多模組工程的常規方法。在我們的示例工程中，存在一個父工程，它包含了兩個子工程（模組），一個core模組，一個webapp模組，webapp模組依賴於core模組。這是一種很常見的工程劃分方式，即core模組中包含了某個領域的核心業務邏輯，webapp模組通過呼叫core模組中服務類來建立前端網站。這樣將核心業務邏輯和前端展現分離開來，如果之後決定開發另一套桌面應用程式，那麼core模組是可以重用在桌面程式中。

 

首先通過Maven的Archetype外掛建立一個父工程，即一個pom型別的Maven工程，其中只包含一個pom.xml檔案：

 

mvn archetype:generate -DgroupId=me.davenkin -DartifactId=maven-multi-module -DarchetypeGroupId=org.codehaus.mojo.archetypes -DarchetypeArtifactId=pom-root -DinteractiveMode=false

 

以上命令在當前目錄下建立了一個名為maven-multi-module的目錄，該目錄便表示這個pom型別的父工程，在該目錄只有一個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> <groupId>me.davenkin</groupId> <artifactId>maven-multi-module</artifactId> <version>1.0-SNAPSHOT</version> <packaging>pom</packaging> <name>maven-multi-module</name> </project>

 

 

這個pom.xml非常簡單，最值得一看的是其中的“<packaging>pom</packaging>”，表示該工程為pom型別。其他的Maven工程型別還有jar、war、ear等。

 

此時，父工程便建立好了，接下來我們建立core模組，由於core模組屬於maven-multi-module模組，我們將工作目錄切換到maven-multi-module目錄下，建立core模組命令如下：

 

mvn archetype:generate -DgroupId=me.davenkin -DartifactId=core  -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

 

這裡我們使用了Archetype外掛的maven-archetype-quickstart，它建立一個jar型別的模組。此時，如果我們在開啟maven-multi-module模組的pom.xml會發現，其中多了以下內容：

 

 <modules>

   <module>core</module> </modules>

 

 

這裡的core即是我們剛才建立的core模組，再看看core模組中的pom.xml檔案：

 

<?xml version="1.0"?>

<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <modelVersion>4.0.0</modelVersion> <parent> <artifactId>maven-multi-module</artifactId> <groupId>me.davenkin</groupId> <version>1.0-SNAPSHOT</version> </parent> <groupId>me.davenkin</groupId> <artifactId>core</artifactId> <version>1.0-SNAPSHOT</version> <name>core</name> <url>http://maven.apache.org</url> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies> </project>

 

 

請注意裡面的  “<parent>...  </parent>”，它將maven-multi-module模組做為了自己的父模組。這裡我們看出，當建立core模組時，Maven將自動識別出已經存在的maven-multi-module父模組，然後分別建立兩個方向的指引關係，即在maven-multi-module模組中將core作為自己的子模組，在core模組中將maven-multi-module作為自己的父模組。要使Maven有這樣的自動識別功能，我們需要在maven-multi-module目錄下建立core模組（請參考前文），不然，core模組將是一個獨立的模組，但是我們可以通過手動修改兩個模組中的pom.xml檔案來建立他們之間的父子關係，從而達到同樣的目的。

 

依然在maven-multi-module目錄下，通過與core相同的方法建立webapp模組：

 

mvn archetype:generate -DgroupId=me.davenkin -DartifactId=webapp -DarchetypeArtifactId=maven-archetype-webapp -DinteractiveMode=false

 

 

這裡的maven-archetype-webapp表明Maven建立的是一個war型別的工程模組。此時再看maven-multi-module模組的pom.xml檔案，其中的<modules>中多了一個webapp模組：

 

<modules>

   <module>core</module> <module>webapp</module> </modules>

 

 

而在webapp模組的pom.xml檔案中，也以 “<parent>...  </parent>”的方式將maven-multi-module模組宣告為自己的父模組，這些同樣是得益於Maven自動識別的結果。

 

此時，在maven-multi-module目錄下，我們執行以下命令完成整個工程的編譯、打包和安裝到本地Maven Repository的過程：

 

mvn clean install

 

  

（二）手動新增子模組之間的依賴關係

 

此時我們雖然建立了一個多模組的Maven工程，但是有兩個問題我們依然沒有解決：

 

（1）沒有發揮Maven父模組的真正作用（配置共享）

（2）webapp模組對core模組的依賴關係尚未建立

 

針對（1），Maven父模組的作用本來是使子模組可以繼承並覆蓋父模組中的配置，比如dependency等，但是如果我們看看webapp和core模組中pom.xml檔案，他們都聲明瞭對Junit的依賴，而如果多個子模組都依賴於相同的類庫，我們應該將這些依賴配置在父模組中，繼承自父模組的子模組將自動獲得這些依賴。所以接下來我們要做的便是：將webapp和core模組對junit的依賴刪除，並將其遷移到父模組中。

 

對於（2），Maven在建立webapp模組時並不知道webapp依賴於core，所以這種依賴關係需要我們手動加入，在webapp模組的pom.xml中加入對core模組的依賴：

 

       <dependency>

           <groupId>me.davenkin</groupId> <artifactId>core</artifactId> <version>1.0-SNAPSHOT</version> </dependency>

 

 

此時再在maven-multi-module目錄下執行 “mvn clean install”，Maven將根據自己的Reactor機制決定哪個模組應該先執行，哪個模組應該後執行。比如，這裡的webapp模組依賴於core模組，那麼Maven會先在core模組上執行“mvn clean install”，再在webapp模組上執行相同的命令。在webapp上執行“mvn clean install”時，由於core模組已經被安裝到了本地的Repository中，webapp便可以順利地找到所依賴的core模組。

 

總的來看，此時命令的執行順序為maven-multi-module -> core -> webapp，先在maven-multi-module上執行是因為其他兩個模組都將它作為父模組，即對它存在依賴關係，又由於core被webapp依賴，所以接下來在core上執行命令，最後在webapp上執行。

 

這裡又有一個問題：為什麼非得在maven-multi-module目錄下執行 “mvn clean install”？答案是，並不是非得如此，只是你需要搞清楚Maven的工作機制。在maven-multi-module目錄下執行，即是在父工程中執行，此時Maven知道父模組所包含的所有子模組，並會自動按照模組依賴關係處理執行順序。如果只在子模組中執行，那麼Maven並不知道它對其他模組的依賴關係。舉個例子，當在webapp中執行 “mvn clean install”，Maven發現webapp自己依賴於core，此時Maven會在本地的Repository中去找core，如果存在，那麼你很幸運，如果不存在，那麼對不起，執行失敗，說找不到core，因為Maven並不會先將core模組安裝到本地Repository。此時你需要做的是，切換到core目錄，執行“mvn clean install”將core模組安裝到本地Repository，再切換回webapp目錄，執行“mvn clean install”，萬事才大吉。

 

多麼繁瑣的步驟，此時你應該能體會到在maven-multi-module下執行Maven命令的好處了吧。總結一下：在maven-multi-module下執行“mvn clean install”， Maven會在每個模組上執行該命令，然後又發現webapp依賴於core，此時他們之間有一個協調者（即父工程），它知道將core作為webapp的依賴，於是會先在core模組上執行“mvn clean install”，當在webapp上執行命令時，無論先前的core模組是否存在於本地Repository中，父工程都能夠獲取到core模組（如果不存在於本地Repository，它將現場編譯core模組，再將其做為webapp的依賴，比如此時使用“mvn clean package”也是能夠構建成功的），所以一切成功。

 

這裡又牽扯到Maven如何查詢依賴的問題，簡單來說，Maven會先在本地Repository中查詢依賴，如果依賴存在，則使用該依賴，如果不存在，則通過pom.xml中的Repository配置從遠端下載依賴到本地Repository中。預設情況下，Maven將使用Maven Central Repository作為遠端Repository。於是你又有問題了：“在pom.xml中為什麼沒有看到這樣的配置資訊啊？”原因在於，任何一個Maven工程都預設地繼承自一個Super POM，Repository的配置資訊便包含在其中。

  

（三）多模組 vs 繼承

 

在文章一開始我們便提到，在Maven中，由多模組（Project Aggregation）和繼承（Project Inheritance）關係並不必同時存在。

 

（1）如果保留webapp和core中對maven-multi-module的父關係宣告，即保留 “<parent>...  </parent>”，而刪除maven-multi-module中的子模組宣告，即“<modules>...<modules>”，會發生什麼情況？此時，整個工程已經不是一個多模組工程，而只是具有父子關係的多個工程集合。如果我們在maven-multi-module目錄下執行“mvn clean install”，Maven只會在maven-multi-module本身上執行該命令，繼而只會將maven-multi-module安裝到本地Repository中，而不會在webapp和core模組上執行該命令，因為Maven根本就不知道這兩個子模組的存在。另外，如果我們在webapp目錄下執行相同的命令，由於由子到父的關係還存在，Maven會在本地的Repository中找到maven-multi-module的pom.xml檔案和對core的依賴（當然前提是他們存在於本地的Repository中），然後順利執行該命令。

 

這時，如果我們要釋出webapp，那麼我們需要先在maven-multi-module目錄下執行“mvn clean install”將最新的父pom安裝在本地Repository中，再在core目錄下執行相同的命令將最新的core模組安裝在本地Repository中，最後在webapp目錄下執行相同的命令完成最終war包的安裝。麻煩。

 

（2）如果保留maven-multi-module中的子模組宣告，而刪除webapp和core中對maven-multi-module的父關係宣告，又會出現什麼情況呢？此時整個工程只是一個多模組工程，而沒有父子關係。Maven會正確處理模組之間的依賴關係，即在webapp模組上執行Maven命令之前，會先在core模組上執行該命令，但是由於core和webapp模組不再繼承自maven-multi-module，對於每一個依賴，他們都需要自己宣告，比如我們需要分別在webapp和core的pom.xml檔案中宣告對Junit依賴。

 

綜上，多模組和父子關係是不同的。如果core和webapp只是在邏輯上屬於同一個總工程，那麼我們完全可以只宣告模組關係，而不用宣告父子關係。如果core和webapp分別處理兩個不同的領域，但是它們又共享了很多，比如依賴等，那麼我們可以將core和webapp分別繼承自同一個父pom工程，而不必屬於同一個工程下的子模組。更多解析請參考這裡。

 

 

轉 ：https://www.cnblogs.com/davenkin/p/advanced-maven-multi-module-vs-inheritance.html

 

這是一個Maven提高篇的系列，包含有以下文章：

  

1. Maven提高篇系列之（一）——多模組 vs 繼承
2. Maven提高篇系列之（二）——配置Plugin到某個Phase（以Selenium整合測試為例）
3. Maven提高篇系列之（三）——使用自己的Repository(Nexus)
4. Maven提高篇系列之（四）——使用Profile
5. Maven提高篇系列之（五）——處理依賴衝突
6. Maven提高篇系列之（六）——編寫自己的Plugin（本系列完）

  

 

 

通常來說，在Maven的多模組工程中，都存在一個pom型別的工程作為根模組，該工程只包含一個pom.xml檔案，在該檔案中以模組（module）的形式宣告它所包含的子模組，即多模組工程。在子模組的pom.xml檔案中，又以parent的形式宣告其所屬的父模組，即繼承。然而，這兩種宣告並不必同時存在，我們將在下文中講到這其中的區別。

 

（一）建立Maven多模組工程

 

多模組的好處是你只需在根模組中執行Maven命令，Maven會分別在各個子模組中執行該命令，執行順序通過Maven的Reactor機制決定。先來看建立Maven多模組工程的常規方法。在我們的示例工程中，存在一個父工程，它包含了兩個子工程（模組），一個core模組，一個webapp模組，webapp模組依賴於core模組。這是一種很常見的工程劃分方式，即core模組中包含了某個領域的核心業務邏輯，webapp模組通過呼叫core模組中服務類來建立前端網站。這樣將核心業務邏輯和前端展現分離開來，如果之後決定開發另一套桌面應用程式，那麼core模組是可以重用在桌面程式中。

 

首先通過Maven的Archetype外掛建立一個父工程，即一個pom型別的Maven工程，其中只包含一個pom.xml檔案：

 

mvn archetype:generate -DgroupId=me.davenkin -DartifactId=maven-multi-module -DarchetypeGroupId=org.codehaus.mojo.archetypes -DarchetypeArtifactId=pom-root -DinteractiveMode=false

 

以上命令在當前目錄下建立了一個名為maven-multi-module的目錄，該目錄便表示這個pom型別的父工程，在該目錄只有一個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> <groupId>me.davenkin</groupId> <artifactId>maven-multi-module</artifactId> <version>1.0-SNAPSHOT</version> <packaging>pom</packaging> <name>maven-multi-module</name> </project>

 

 

這個pom.xml非常簡單，最值得一看的是其中的“<packaging>pom</packaging>”，表示該工程為pom型別。其他的Maven工程型別還有jar、war、ear等。

 

此時，父工程便建立好了，接下來我們建立core模組，由於core模組屬於maven-multi-module模組，我們將工作目錄切換到maven-multi-module目錄下，建立core模組命令如下：

 

mvn archetype:generate -DgroupId=me.davenkin -DartifactId=core  -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

 

這裡我們使用了Archetype外掛的maven-archetype-quickstart，它建立一個jar型別的模組。此時，如果我們在開啟maven-multi-module模組的pom.xml會發現，其中多了以下內容：

 

 <modules>

   <module>core</module> </modules>

 

 

這裡的core即是我們剛才建立的core模組，再看看core模組中的pom.xml檔案：

 

<?xml version="1.0"?>

<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <modelVersion>4.0.0</modelVersion> <parent> <artifactId>maven-multi-module</artifactId> <groupId>me.davenkin</groupId> <version>1.0-SNAPSHOT</version> </parent> <groupId>me.davenkin</groupId> <artifactId>core</artifactId> <version>1.0-SNAPSHOT</version> <name>core</name> <url>http://maven.apache.org</url> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies> </project>

 

 

請注意裡面的  “<parent>...  </parent>”，它將maven-multi-module模組做為了自己的父模組。這裡我們看出，當建立core模組時，Maven將自動識別出已經存在的maven-multi-module父模組，然後分別建立兩個方向的指引關係，即在maven-multi-module模組中將core作為自己的子模組，在core模組中將maven-multi-module作為自己的父模組。要使Maven有這樣的自動識別功能，我們需要在maven-multi-module目錄下建立core模組（請參考前文），不然，core模組將是一個獨立的模組，但是我們可以通過手動修改兩個模組中的pom.xml檔案來建立他們之間的父子關係，從而達到同樣的目的。

 

依然在maven-multi-module目錄下，通過與core相同的方法建立webapp模組：

 

mvn archetype:generate -DgroupId=me.davenkin -DartifactId=webapp -DarchetypeArtifactId=maven-archetype-webapp -DinteractiveMode=false

 

 

這裡的maven-archetype-webapp表明Maven建立的是一個war型別的工程模組。此時再看maven-multi-module模組的pom.xml檔案，其中的<modules>中多了一個webapp模組：

 

<modules>

   <module>core</module> <module>webapp</module> </modules>

 

 

而在webapp模組的pom.xml檔案中，也以 “<parent>...  </parent>”的方式將maven-multi-module模組宣告為自己的父模組，這些同樣是得益於Maven自動識別的結果。

 

此時，在maven-multi-module目錄下，我們執行以下命令完成整個工程的編譯、打包和安裝到本地Maven Repository的過程：

 

mvn clean install

 

  

（二）手動新增子模組之間的依賴關係

 

此時我們雖然建立了一個多模組的Maven工程，但是有兩個問題我們依然沒有解決：

 

（1）沒有發揮Maven父模組的真正作用（配置共享）

（2）webapp模組對core模組的依賴關係尚未建立

 

針對（1），Maven父模組的作用本來是使子模組可以繼承並覆蓋父模組中的配置，比如dependency等，但是如果我們看看webapp和core模組中pom.xml檔案，他們都聲明瞭對Junit的依賴，而如果多個子模組都依賴於相同的類庫，我們應該將這些依賴配置在父模組中，繼承自父模組的子模組將自動獲得這些依賴。所以接下來我們要做的便是：將webapp和core模組對junit的依賴刪除，並將其遷移到父模組中。

 

對於（2），Maven在建立webapp模組時並不知道webapp依賴於core，所以這種依賴關係需要我們手動加入，在webapp模組的pom.xml中加入對core模組的依賴：

 

       <dependency>

           <groupId>me.davenkin</groupId> <artifactId>core</artifactId> <version>1.0-SNAPSHOT</version> </dependency>

 

 

此時再在maven-multi-module目錄下執行 “mvn clean install”，Maven將根據自己的Reactor機制決定哪個模組應該先執行，哪個模組應該後執行。比如，這裡的webapp模組依賴於core模組，那麼Maven會先在core模組上執行“mvn clean install”，再在webapp模組上執行相同的命令。在webapp上執行“mvn clean install”時，由於core模組已經被安裝到了本地的Repository中，webapp便可以順利地找到所依賴的core模組。

 

總的來看，此時命令的執行順序為maven-multi-module -> core -> webapp，先在maven-multi-module上執行是因為其他兩個模組都將它作為父模組，即對它存在依賴關係，又由於core被webapp依賴，所以接下來在core上執行命令，最後在webapp上執行。

 

這裡又有一個問題：為什麼非得在maven-multi-module目錄下執行 “mvn clean install”？答案是，並不是非得如此，只是你需要搞清楚Maven的工作機制。在maven-multi-module目錄下執行，即是在父工程中執行，此時Maven知道父模組所包含的所有子模組，並會自動按照模組依賴關係處理執行順序。如果只在子模組中執行，那麼Maven並不知道它對其他模組的依賴關係。舉個例子，當在webapp中執行 “mvn clean install”，Maven發現webapp自己依賴於core，此時Maven會在本地的Repository中去找core，如果存在，那麼你很幸運，如果不存在，那麼對不起，執行失敗，說找不到core，因為Maven並不會先將core模組安裝到本地Repository。此時你需要做的是，切換到core目錄，執行“mvn clean install”將core模組安裝到本地Repository，再切換回webapp目錄，執行“mvn clean install”，萬事才大吉。

 

多麼繁瑣的步驟，此時你應該能體會到在maven-multi-module下執行Maven命令的好處了吧。總結一下：在maven-multi-module下執行“mvn clean install”， Maven會在每個模組上執行該命令，然後又發現webapp依賴於core，此時他們之間有一個協調者（即父工程），它知道將core作為webapp的依賴，於是會先在core模組上執行“mvn clean install”，當在webapp上執行命令時，無論先前的core模組是否存在於本地Repository中，父工程都能夠獲取到core模組（如果不存在於本地Repository，它將現場編譯core模組，再將其做為webapp的依賴，比如此時使用“mvn clean package”也是能夠構建成功的），所以一切成功。

 

這裡又牽扯到Maven如何查詢依賴的問題，簡單來說，Maven會先在本地Repository中查詢依賴，如果依賴存在，則使用該依賴，如果不存在，則通過pom.xml中的Repository配置從遠端下載依賴到本地Repository中。預設情況下，Maven將使用Maven Central Repository作為遠端Repository。於是你又有問題了：“在pom.xml中為什麼沒有看到這樣的配置資訊啊？”原因在於，任何一個Maven工程都預設地繼承自一個Super POM，Repository的配置資訊便包含在其中。

  

（三）多模組 vs 繼承

 

在文章一開始我們便提到，在Maven中，由多模組（Project Aggregation）和繼承（Project Inheritance）關係並不必同時存在。

 

（1）如果保留webapp和core中對maven-multi-module的父關係宣告，即保留 “<parent>...  </parent>”，而刪除maven-multi-module中的子模組宣告，即“<modules>...<modules>”，會發生什麼情況？此時，整個工程已經不是一個多模組工程，而只是具有父子關係的多個工程集合。如果我們在maven-multi-module目錄下執行“mvn clean install”，Maven只會在maven-multi-module本身上執行該命令，繼而只會將maven-multi-module安裝到本地Repository中，而不會在webapp和core模組上執行該命令，因為Maven根本就不知道這兩個子模組的存在。另外，如果我們在webapp目錄下執行相同的命令，由於由子到父的關係還存在，Maven會在本地的Repository中找到maven-multi-module的pom.xml檔案和對core的依賴（當然前提是他們存在於本地的Repository中），然後順利執行該命令。

 

這時，如果我們要釋出webapp，那麼我們需要先在maven-multi-module目錄下執行“mvn clean install”將最新的父pom安裝在本地Repository中，再在core目錄下執行相同的命令將最新的core模組安裝在本地Repository中，最後在webapp目錄下執行相同的命令完成最終war包的安裝。麻煩。

 

（2）如果保留maven-multi-module中的子模組宣告，而刪除webapp和core中對maven-multi-module的父關係宣告，又會出現什麼情況呢？此時整個工程只是一個多模組工程，而沒有父子關係。Maven會正確處理模組之間的依賴關係，即在webapp模組上執行Maven命令之前，會先在core模組上執行該命令，但是由於core和webapp模組不再繼承自maven-multi-module，對於每一個依賴，他們都需要自己宣告，比如我們需要分別在webapp和core的pom.xml檔案中宣告對Junit依賴。

 

綜上，多模組和父子關係是不同的。如果core和webapp只是在邏輯上屬於同一個總工程，那麼我們完全可以只宣告模組關係，而不用宣告父子關係。如果core和webapp分別處理兩個不同的領域，但是它們又共享了很多，比如依賴等，那麼我們可以將core和webapp分別繼承自同一個父pom工程，而不必屬於同一個工程下的子模組。更多解析請參考這裡。

 

 

轉 ：https://www.cnblogs.com/davenkin/p/advanced-maven-multi-module-vs-inheritance.html