from:http://www.infoq.com/cn/news/2010/12/xxb-maven-2-pom

重構是廣大開發者再熟悉不過的技術，在Martin Fowler的《重構——改善既有代碼的設計》一書中，其定義為“重構(名詞):對軟件內部結構的一種調整,目的是在不改變軟件之可察行為前提下,提高其可理解性,降低其修改成本.”以及“重構(動詞):使用一系列重構準則(手法),在不改變軟件之可察行為前提下,調整其結構.”。重構能夠改善軟件設計，使代碼更易讀，更容易找出bug，并幫助你更快速地編碼。較之于一般的代碼來說，Maven的POM簡單很多，不過隨著項目的成長，模塊的增多，POM的內容也會變多，這個時候，我們可以對POM進行重構，在保持構建成功的前提下，簡化POM內容，使其更簡潔易懂。

前提

大家都知道，如果沒有單元測試為前提，對代碼進行重構是非常危險的。同樣，在重構POM之前，項目應該有足夠的自動化測試保證POM重構不會破壞構建。例如，重構POM的時候可能會刪除或添加依賴，造成依賴版本變化，依賴范圍變化，插件版本變化等等，這些變化可能會導致項目編譯失敗，或者測試失敗。在自動化測試及構建的基礎上，最好能夠有持續集成環境，以保證POM的修改可能造成的問題能夠及時地被發現和修復。筆者目前工作的項目有一個對應的持續集成任務，該任務基于Hudson，每10分鐘檢查一次SCM，如果發現變更則構建項目，并反饋結果。這樣，我就不用擔心自己修改POM會引入潛在的問題。

增還是刪

有時候這個答案是很顯然的，當你的POM中存在一些依賴或者插件配置，但實際代碼沒有用到這些配置的時候，應該盡早刪掉它們以免給人帶來困惑。

還有一種常見的情況，我們可以刪掉一些POM的元素，例如POM中配置了繼承，當前模塊與父模塊使用同樣的groupId和version時，就可以將<groupId>和<version>元素刪除，因為它們可以從父模塊繼承而來，重復配置沒有什么意義。

<project><modelVersion>4.0.0</modelVersion><parent><groupId>com.juvenxu.sample</groupId><artifactId>sample-parent</artifactId><version>0.0.1-SNAPSHOT</version></parent><artifactId>sample-foo</artifactId><packaging>jar</packaging> ... </project>

上述配置就sample-foo就沒有groupId和version，需要注意的是，artifactId是不能被刪除的，因為該元素不能也不應該被繼承，父子模塊應當使用不同的artifactId值。

除了刪之外，有些時候我們還需要在POM中增加一些XML元素，目的是為了讓POM更清晰易讀，且保證Maven構建的穩定性。考慮如下的插件配置：

<plugin><artifactId>maven-compiler-plugin</artifactId><configuration><source>1.5</source><target>1.5</target></configuration> </plugin>

雖然沒有groupId及version，但這段配置是完全合法的。當插件沒有groupId配置的時候，Maven會認為它是官方插件而自動使用org.apache.maven.plugins作為groupId，當插件沒有version配置的時候，Maven則會使用最新的版本（Maven 2會使用最新的版本，包括SNAPSHOT，而Maven 3則只使用最新的非SNAPSHOT版本）。這段配置有兩個問題，首先，如果讓一個不熟悉Maven的開發者來看這段配置，他會感到費解，groupId和version究竟是什么呢？這與不清晰的代碼是一個意思，有時候一些程序員為了讓代碼更短，會采用一些奇怪的語法和變量名，雖然代碼量是少了，但溝通成本增加了，得不償失。其次，讓Maven猜測版本會有潛在的風險，因為插件的最新版本可能會變化，而這種變化對于Maven使用者來說通常是隱藏的，特別是在Maven 2中，甚至可能引入SNAPSHOT版本的插件，這是非常危險的。基于這兩個原因，使用插件的時候，我們應當配置清楚groupId和version，如：

<plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-compiler-plugin</artifactId><version>2.3.2</version><configuration><source>1.5</source><target>1.5</target></configuration> </plugin>

基于類似的原因，在配置項目依賴的時候，我們也應當一直顯式地寫明依賴版本，以避免Maven在不同的時刻引入不同版本的依賴而導致項目構建的不穩定。

除了上面提到的增刪點之外，Maven官方還提供了一個非常有用的Maven Dependency Plugin來幫助我們分析項目中哪些依賴配置應該刪除，那些依賴配置應該增加。Maven Dependency Plugin的analyze目標能夠幫助分析項目依賴，例如運行命令?mvn dependency:analyze?，可以看到如下輸出：

[INFO] --- maven-dependency-plugin:2.1:analyze (default-cli) @ sample-bar --- [WARNING] Used undeclared dependencies found: [WARNING] org.springframework:spring-context:jar:2.5.6:compile [WARNING] Unused declared dependencies found: [WARNING] org.springframework:spring-core:jar:2.5.6:compile [WARNING] org.springframework:spring-beans:jar:2.5.6:compile [INFO] ------------------------------------------------------------------------

這里的 Used undeclared dependencies 是指那些在項目中直接使用到的，但沒有在POM中配置的依賴。例如該例中可能項目中的一些類有關于spring-context的Java import聲明，但spring-context這個依賴實際是通過傳遞性依賴進入classpath的，這就意味者潛在的風險。一般來說我們對直接依賴的版本變化會比較清楚，因為那是我們自己直接配置的，但對于傳遞性依賴的版本變化，就會比較模糊，當這種變化造成構建失敗的時候，就很難找到原因。因此我們應當增加這些 Used undeclared dependencies 。

依賴分析還提供了 Unused declared dependencies 供我們參考，這表示那些我們配置了，但并未直接使用的依賴。需要注意的時，對于這些依賴，我們不該直接簡單地刪除。由于dependency:analyze只分析編譯主代碼和測試代碼使用的依賴，一些執行測試和運行時的依賴它發現不了，因此還需要人工分析。通常情況，Unused declared dependencies 還是能幫助我們發現一些無用的依賴配置。

最后，還一些重要的POM內容通常被大多數項目所忽略，這些內容不會影響項目的構建，但能方便信息的溝通，它們包括項目URL，開發者信息，SCM信息，持續集成服務器信息等等，這些信息對于開源項目來說尤其重要。對于那些想了解項目的人來說，這些信息能他們幫助找到想要的信息，基于這些信息生成的Maven站點也更有價值。相關的POM配置很簡單，如：

<project><description>...</description><url>...</url><licenses>...</licenses><organization>...</organization><developers>...</developers><issueManagement>...</issueManagement><ciManagement>...</ciManagement><mailingLists>...</mailingLists><scm>...</scm> </project>

小結

無論是對POM內容進行增還是刪，其目的都是一樣的，就是為了讓POM更清晰易懂且讓構建更穩定。從這點來說，POM重構與一般的代碼重構是類似的。需要謹記的是，重構的前提是完善的自動化測試和持續集成。本文介紹的單個POM規模的重構，下篇文章筆者會介紹多模塊項目的POM重構等內容。

總結

以上是生活随笔為你收集整理的许晓斌_Maven实战（二）——POM重构之增还是删的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。