Maven 將作為一個普通的構建系統，被人們重新認識，并且它將超越 Java™ 技術。本文不打算成為一篇 Maven 教程，而是將 Maven 與其他技術進行比較，讓您洞察 Maven 與 Eclipse 相適應的地方，以及如何使這些工具相互協作。
在過去幾年中，Maven 已經不僅僅是 Java 世界的一個時髦話題。自 2001 年起，Maven 已經成為構建工具領域的先驅。近幾年，人們常拿它與 Ant 比較。因為 Maven 與 Ant 有一些顯而易見的相似之處，所以拿它們倆作比較似乎是很自然的事。比如說，在兩種情況下，XML 腳本都是可用的；兩種工具都可以生產工件；它們還可以共享相同的分類法和概念，比如 項目（project）、目標（target）與 目標（goal），以及 依賴關系（depends） 和 先決條件（prereqs）。但它們實質上有很大的差別。Ant 只是一個 XML 腳本工具，而 Maven 是一個普通的構建工具，它關注的重點是一個叫做項目對象模型（POM）的概念。POM 暴露的是粗粒度的、面向構建的任務，這些任務被稱為目標，它們提供了一些準則，幫助您開發構建方法和實現佳實踐。
在某些方面，Maven 屬于軟件工廠 工具家族（參閱 參考資料），盡管目前它仍在外圍。更確切地說，諸如 Maven 之類的構建工具是軟件工廠領域中必不可少的。
軟件工廠
通過顯著提高自動開發的級別，軟件工廠提供了一個花費更少、更靈活的應用程序開發方法。根據 Software Factories Web 站點的說法，“軟件工廠是一個軟件產品線，它根據構建特殊種類的應用程序的方法，配置一些可擴展的開發工具……提供打包的內容……以及指導”（參閱 參考資料）。軟件工廠涉及三個主要概念：
模式，提供了一些元數據，描述組成應用程序的不同工件的結構，以及它們是如何交互的。
一個或多個模板，提供了啟動程序工具箱，以及構建應用程序所需的其他任何東西。
可擴展的開發環境，用于配置、定制和裝配組件。
如今，這類工具已經逐漸引起了認識到它們的價值的那些工具制造人員、工具開發人員和軟件編輯的注意。這些工具促進了軟件開發過程的工業化，降低了投入市場的成本和時間，同時還提高了生產率，加快了對進化需求的反應。
仔細查看一下 Maven 的主要特性，您會認識到 Maven 與軟件工廠之間的相似之處：Maven 使用 POM 作為元數據來描述項目結構，并通過通用應用程序插件來獲得可擴展的項目模板。因為 Maven 非常靈活并且是開放源碼的，所以很容易推斷和設想 Maven 是軟件工廠平臺中的一個核心組件。但是，還有另一種說法。上述類比并不完全，因為目前的 Maven 缺乏專用的開發環境，而這類環境有助于創建特定于域或特定于企業的插件和模板，并允許您輕松地配置項目或定制行為。
不過，Maven 的主要目標是標準化構建過程，并保證代碼構建-測試-部署（CBTD）循環中的質量和易再現性（easy reproducibility）。它還可以制定度量標準，幫助您了解開發狀態。CBTD 本體論在軟件工程領域已經不再新鮮，但 Maven 可以使您標準化這種本體論，并通過抽象這種理論，將它想像成一個完整的實體。考慮到不斷增長的項目的復雜性，標準化成為一種迫切需要。擴建 的概念，我們稱之為元構建，因為其無可估量的價值以及保證下一級質量的特性，正逐漸被人們認識。持續集成（continuous integration）是建立在這個概念的基礎之上，但它也應用了在 IDE 上下文之外的地方進行構建的能力。
模糊的界限
使用過 Java 技術的人應該都聽說過 Eclipse。2001 年年中的時候，Eclipse 推出了它的第一個版本，標志其成熟的是它為集成開發環境（IDE）提供了一個機會，特別是為 Java 開發人員（不嚴謹地說）提供了一個機會。Eclipse 是一種開放的、以語言為中心的平臺，也可以將它用作教育性項目和研究項目的基礎平臺，其中一些平臺捐贈給了 Eclipse 團體（ 請參閱 參考資料）。像 Microsoft® 已經采用軟件工廠方法一樣，Eclipse 也開始轉向模型驅動開發（MDD）方向，并且近已經公布了一個新的項目提議 —— 模型驅動的開發集成（MDDi）。根據該提議，“Eclipse MDDi 項目專用于平臺的實現……其設計目標是支持各種建模語言（統一建模語言或特定于域的語言）和模型驅動的技術。”
漸漸地，一些工具開始假定某些特性可以完全并且順利地集成在一起，Maven 和 Eclipse（即使作為一個簡單的 IDE）也不例外。因此，從構建的角度來看，二者似乎出現了重疊，如圖 1 所示。
圖 1. 擴建的概念
圖 1 描述的實際上是以前討論的擴建概念。正如以前定義的那樣，整個擴建過程包括幾個任務，同時還表示了一個元構建實例。任務可以是以下兩種類型之一：原子任務是細粒度的，并且是上下文不明確的，這種任務的兩個實例幾乎是相同的；宏觀任務是復合任務，它充當微觀任務的容器。
構建，從擴展的意義上說，只處理宏觀任務；原子任務的觸發取決于配置。這意味著用戶對系統有著較高層次的看法，這使得系統更易于維護和發展。
此外，Maven 和 Eclipse 都是開放的，并且很容易通過插件擴展它們，使其滿足您的需要。但是，因為它們針對的受眾不同，所以它們之間的相似性也到此為止：多數 Eclipse 終用戶是一些開發人員；而 Maven 主要針對的是一些構建管理人員。盡管如此，Maven 仍然是一個命令行工具。雖然圖形用戶界面（GUI）是按照 Jason Van Zyl（Maven 的制造者和架構師）指示的方向開發的，但 Maven 目前仍然沒有幫助用戶執行特殊任務的特定 GUI，比如創建或更新配置，或者只用一個鼠標單擊發起構建。
上面描述的典型構建順序在 Eclipse 中不像在 Maven 中那么順利。Eclipse 的特性之一是開發 環境造成構建過程不連續，這要歸因于一些人為因素：并不是每次成功編譯之后都進行測試、所有測試沒必要一次運行、可以跳過一些微觀任務，等等。各種因素都會導致產生差異，這是為什么開發人員每天至少必須運行一次完整的構建過程，以確信他們沒有破壞什么的原因。
不過，因為 Eclipse 是一個可擴展平臺，所以它受到許多用戶社區的支持，這使它成為駐留 Maven 驅動的開發、允許開發人員和構建管理人員以某種簡單的方式進行協作的理想之地。
將 Maven 集成到 Eclipse 中
Mevenide 是 Codehaus 主辦的一個項目，旨在通過將 Maven 集成到 IDE 中，簡化 Maven 的使用（參閱 參考資料）。現在，Borland Software 的 JBuilder、NetBeans 和 Eclipse 都受到支持。其他一些項目也部分地將 Maven 集成到 Eclipse 中，這樣，可以與 Mevenide（如 Maven Workshop）共享一些特性。除了增加 Maven 的易用性之外，為什么需要這種插件？
通過提供一些工具和視圖，讓您了解 Maven 隱藏的復雜性并改進團隊環境中的協作，Mevenide for Eclipse 提高了生產率。從協作的角度來看，假如構建已經被 Maven 化了，那么有用的特性是 Eclipse 項目元數據與 Maven 元數據之間的雙向同步。如果開發人員忘記在向 Eclipse 中添加一個依賴關系之后更新 POM，那么該怎么辦？如果重構無法傳播到 Maven，該怎么辦？構建可能會中斷，或者一些單元測試可能被拒絕，因此，真的需要使 Eclipse 元數據和 Maven 元數據保持同步。Mevenide 監聽元數據的變化，并使您能夠很容易地確定元數據不匹配的地方，這可以防止進行被嚴重破壞的構建。
但 POM 并不只是關于依賴關系和項目布局的。它還包含一些不用于結構上的項目管理信息，比如版本號、名稱、ID 和源儲存庫的位置。Eclipse 元數據并不總是反映所有這些信息。因此，需要另一個編輯這些信息的方法。為此，Mevenide 提供了一個圖形編輯器，該編輯器使 POM 的維護變得更容易，并允許您避開一些煩瑣的、容易出錯的原始 XML 手工編輯。每個 POM 語義部分都被表示為一個編輯器頁，這增強了模型的整體可靠性。此外，為了大限度地減少創建 POM 的無聊過程，Mevenide 提供了一個相當簡單的、可擴展的 POM 模板機制。
阻止 Maven 在 Eclipse 之外的地方運行的能力是從類似 Mevenide 的插件中容易獲得的一項功能。您可以選擇某些執行任務（用 Maven 的術語來講是 目標），這些任務可以是通過 Maven 插件全局定義的任務，也可以是依賴于項目的任務，或者，您可以通過定義構建敏感的變量來定制構建。Eclipse 控制臺上只顯示了一些相關的選項（即在 IDE 的上下文中相關），對于其他任何插件，控制臺上只輸出構建日志。這一特性非常重要，因為它避免了在控制臺與 Eclipse 之間不停地來回奔波。
Mevenide 還集成了其他許多幫助方法特性，但它們不是很重要。例如，您可以定義給定目標與文件模式之間的關系，這樣，可以根據工作空間增加的增量來激活那些任務。您還可以瀏覽工件儲存庫，或者根據名稱搜索某個給定的工件（一個工件 是一個構建結果，它可以是 JAR 文件、可執行文件或者是一個完整的 Web 站點）。然后，可以重定向到 Mevenide 站點，獲得完整的特性列表。
不過，仍然還有一個問題：即使 Mevenide 增強了生產率和易用性，但您仍然必須認識到哪些工具可以在特殊環境中滿足您的需要。通過 Maven Console 運行 Maven 會話可能非常耗時，所以，為了獲得較高的生產率，在對會話進行編碼期間，應該改為使用 JUnit 集成的 Eclipse 支持來運行測試，并依賴于 Eclipse 的內部編譯器來生成可執行的文件。但在向源代碼儲存庫提交任何東西之前，應該確保 POM 是同步的，并回滾所有不需要的 .classpath 或 .project 修改 —— 也是說，假設這些文件都是在源代碼控制之下，這可能是有爭議的。這個話題在 Martin Van den Bemt 的 blog 中討論過（參閱 參考資料）。
結束語
盡管 Maven 和 Eclipse 具有不同的特性，但從構建的角度看，它們在某些地方可能出現重疊。它們之間存在的對立似乎也相當多，但我們很容易克服這些，通過努力終使它們相互協作，共創一片沃土。諸如 Mevenide 之類的工具可以使 Maven 和 Eclipse 順利合作，并使它們保持同步，但您必須認識到，在某一個給定的開發階段，哪種工具能滿足您的需要。
盡管 Maven 作為質量保證過程中的一個重要因素，正逐漸被人們所認可，但在將它集成到開發環境（尤其是 Eclipse）中，使 Maven 成為一等 IDE 公民這一點上，還有待提高。到那時，我們可以考慮其他的 Maven 用例，比如說，更進一步地將它集成到全局開發過程中，以及像 Eclipse 這樣的可擴展環境如何幫助實現這些集成。
本系列的下一部分將更詳細地查看 Mevenide 的能力，以及如何使用該工具實現佳實踐，并從 Maven 和 Eclipse 中獲得大好處。
