maven最佳實踐：劃分模組

所有用Maven管理的真實的專案都應該是分模組的，每個模組都對應著一個pom.xml。它們之間通過繼承和聚合（也稱作多模組，multi-module）相互關聯。那麼，為什麼要這麼做呢？我們明明在開發一個專案，劃分模組後，匯入Eclipse變成了N個專案，這會帶來複雜度，給開發帶來不便。

 

為了解釋原因，假設有這樣一個專案，很常見的Java Web應用。在這個應用中，我們分了幾層：

• Dao層負責資料庫互動，封裝了Hibernate互動的類。
• Service層處理業務邏輯，放一些Service介面和實現相關的Bean。
• Web層負責與客戶端互動，主要有一些Structs的Action類。

對應的，在一個專案中，我們會看到一些包名：

• org.myorg.app.dao
• org.myorg.app.service
• org.myorg.app.web
• org.myorg.app.util

這樣整個專案的框架就清晰了，但隨著專案的進行，你可能會遇到如下問題：

1. 這個應用可能需要有一個前臺和一個後臺管理端（web或者swing），你發現大部分dao，一些service，和大部分util是在兩個應用中可。這樣的問題，你一週內遇到了好幾次。
2. pom.xml中的依賴列表越來越長以重用的，但是，由於目前只有一個專案（WAR），你不得不新建一個專案依賴這個WAR，這變得非常的噁心，因為在Maven中配置對WAR的依賴遠不如依賴JAR那樣簡單明瞭，而且你根本不需要org.myorg.app.web。有人修改了dao，提交到svn並且不小心導致build失敗了，你在編寫service的程式碼，發現編譯不過，只能等那人把dao修復了，你才能繼續進行，很多人都在修改，到後來你根本就不清楚哪個依賴是誰需要的，漸漸的，很多不必要的依賴被引入。甚至出現了一個依賴有多個版本存在。
3. build整個專案的時間越來越長，儘管你只是一直在web層工作，但你不得不build整個專案。
4. 某個模組，比如util，你只想讓一些經驗豐富的人來維護，可是，現在這種情況，每個開發者都能修改，這導致關鍵模組的程式碼質量不能達到你的要求。
   

我們會發現，其實這裡實際上沒有遵守一個設計模式原則：“高內聚，低耦合”。雖然我們通過包名劃分了層次，並且你還會說，這些包的依賴都是單向的，沒有包的環依賴。這很好，但還不夠，因為就構建層次來說，所有東西都被耦合在一起了。因此我們需要使用Maven劃分模組。

 

一個簡單的Maven模組結構是這樣的：

 

---- app-parent

             |-- pom.xml (pom)

             |

             |-- app-util

             |        |-- pom.xml (jar)

             |

             |-- app-dao

             |        |-- pom.xml (jar)

             |

             |-- app-service

             |        |-- pom.xml (jar)

             |

             |-- app-web

                      |-- pom.xml (war)   

 

上述簡單示意圖中，有一個父專案(app-parent)聚合很多子專案（app-util, app-dao, app-service, app-web）。每個專案，不管是父子，都含有一個pom.xml檔案。而且要注意的是，小括號中標出了每個專案的打包型別。父專案是pom,也只能是pom。子專案有jar，或者war。根據它包含的內容具體考慮。

 

這些模組的依賴關係如下：

 

app-dao      --> app-util

app-service --> app-dao

app-web     --> app-service

 

注意依賴的傳遞性（大部分情況是傳遞的，除非你配置了特殊的依賴scope），app-dao依賴於app-util，app-service依賴於app-dao，於是app-service也依賴於app-util。同理，app-web依賴於app-dao,app-util。

 

用專案層次的劃分替代包層次的劃分能給我們帶來如下好處：

1. 方便重用，如果你有一個新的swing專案需要用到app-dao和app-service，新增對它們的依賴即可，你不再需要去依賴一個WAR。而有些模組，如app-util，完全可以漸漸進化成公司的一份基礎工具類庫，供所有專案使用。這是模組化最重要的一個目的。
2. 由於你現在劃分了模組，每個模組的配置都在各自的pom.xml裡，不用再到一個混亂的紛繁複雜的總的POM中尋找自己的配置。
3. 如果你只是在app-dao上工作，你不再需要build整個專案，只要在app-dao目錄執行mvn命令進行build即可，這樣可以節省時間，尤其是當專案越來越複雜，build越來越耗時後。
4. 某些模組，如app-util被所有人依賴，但你不想給所有人修改，現在你完全可以從這個專案結構出來，做成另外一個專案，svn只給特定的人訪問，但仍提供jar給別人使用。
5. 多模組的Maven專案結構支援一些Maven的更有趣的特性（如DepencencyManagement），這留作以後討論。

接下來討論一下POM配置細節，實際上非常簡單，先看app-parent的pom.xml：

Maven的座標GAV（groupId, artifactId, version）在這裡進行配置，這些都是必須的。特殊的地方在於，這裡的packaging為pom。所有帶有子模組的專案的packaging都為pom（也就是說，父pom的packaging都為pom）。packaging如果不進行配置，它的預設值是jar，代表Maven會將專案打成一個jar包。

該配置重要的地方在於modules，例子中包含的子模組有app-util, app-dao, app-service, app-war。在Maven build app-parent的時候，它會根據子模組的相互依賴關係整理一個build順序，然後依次build。(注意，經過測試，此處時根據相互依賴關係來整理build順序的，並不是根據module中配置的順序。)

這就是一個父模組大概需要的配置，接下來看一下子模組符合配置繼承父模組。

app-util模組繼承了app-parent父模組，因此這個POM的一開始就宣告瞭對app-parent的引用，該引用是通過Maven座標GAV實現的。而關於專案app-util本身，它卻沒有宣告完整GAV，這裡我們只看到了artifactId。這個POM並沒有錯，groupId和version預設從父模組繼承了。實際上子模組從父模組繼承一切東西，包括依賴，外掛配置等等。

此外app-util配置了一個對於commons-lang的簡單依賴，這是最簡單的依賴配置形式。大部分情況，也是通過GAV引用的。

再看一下app-dao，它也是繼承於app-parent，同時依賴於app-util：

該配置和app-util的配置幾乎沒什麼差別，不同的地方在於，依賴變化了，app-dao依賴於app-util。這裡要注意的是version的值為${project.version}，這個值是一個屬性引用，指向了POM的project/version的值，也就是這個POM對應的version。由於app-dao的version繼承於app-parent，因此它的值就是1.0-SNAPSHOT。而app-util也繼承了這個值，因此在所有這些專案中，我們做到了保持版本一致。

這裡還需要注意的是，app-dao依賴於app-util，而app-util又依賴於commons-lang，根據傳遞性，app-dao也擁有了對於commons-lang的依賴。

app-service我們跳過不談，它依賴於app-dao。我們最後看一下app-web：

app-web依賴於app-service，因此配置了對其的依賴。

由於app-web是我們最終要部署的應用，因此它的packaging是war。為此，你需要有一個目錄src/main/webapp。並在這個目錄下擁有web應用需要的檔案，如/WEB-INF/web.xml。沒有web.xml，Maven會報告build失敗，此外你可能還會有這樣一些子目錄：/js, /img, /css ... 。

 

看看Maven是如何build整個專案的，我們在 app-parent 根目錄中執行 mvn clean install ，輸出的末尾會有大致這樣的內容：

 

...

...

[INFO] [war:war]
[INFO] Packaging webapp
[INFO] Assembling webapp[app-web] in [/home/juven/workspaces/ws-others/myapp/app-web/target/app-web-1.0-SNAPSHOT]
[INFO] Processing war project
[INFO] Webapp assembled in[50 msecs]
[INFO] Building war: /home/juven/workspaces/ws-others/myapp/app-web/target/app-web-1.0-SNAPSHOT.war
[INFO] [install:install]
[INFO] Installing /home/juven/workspaces/ws-others/myapp/app-web/target/app-web-1.0-SNAPSHOT.war to /home/juven/.m2/repository/org/myorg/myapp/app-web/1.0-SNAPSHOT/app-web-1.0-SNAPSHOT.war
[INFO] 
[INFO] 
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] ------------------------------------------------------------------------
[INFO] app-parent ............................................ SUCCESS [1.191s]
[INFO] app-util .............................................. SUCCESS [1.274s]
[INFO] app-dao ............................................... SUCCESS [0.583s]
[INFO] app-service ........................................... SUCCESS [0.593s]
[INFO] app-web ............................................... SUCCESS [0.976s]    注意順序
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4 seconds
[INFO] Finished at: Sat Dec 27 08:20:18 PST 2008
[INFO] Final Memory: 3M/17M
[INFO] ------------------------------------------------------------------------

 

注意Reactor Summary，整個專案根據我們希望的順序進行build。Maven根據我們的依賴配置，智慧的安排了順序，app-util, app-dao, app-service, app-web。

 

最後，你可以在 app-web/target 目錄下找到檔案 app-web-1.0-SNAPSHOT.war ，開啟這個war包，在 /WEB-INF/lib 目錄看到了 commons-lang-2.4.jar，以及對應的app-util, app-dao, app-service 的jar包。Maven自動幫你處理了打包的事情，並且根據你的依賴配置幫你引入了相應的jar檔案。

 

使用多模組的Maven配置，可以幫助專案劃分模組，鼓勵重用，防止POM變得過於龐大，方便某個模組的構建，而不用每次都構建整個專案，並且使得針對某個模組的特殊控制更為方便。本文同時給出了一個實際的配置樣例，展示瞭如何使用Maven配置多模組專案。