我有一個我在Java中做的項目。這是一個非常簡單的web應用程序。它運行在Linux服務器上的Tomcat中，並使用MySQL數據庫。大部分代碼都是用Spring框架編寫的。它有很多單元測試。當我編寫它在Eclipse中。當我部署應用程序時，我運行幾個shell腳本將WAR文件移動到Web服務器，執行數據庫更新並更改apache配置。我是唯一開發它的開發人員，現在只能部署到1個環境（生產），儘管有一天我可能也想要一個測試或登臺環境。我通過Eclipse插件使用SVN版本控制。思考學習Maven
我總是聽說有人在項目中使用Maven。既然有這麼多人在使用它，我只能說自己一定很好。我想在業餘時間學習。唯一的問題是我爲什麼要使用Maven不太滿意？我的第一段聽起來像是一個適合Maven的項目嗎？對於與數據庫交互的項目它有什麼特別的優勢嗎？
您的項目聽起來不像適合Maven的項目。你似乎有一個有效的開發環境。爲什麼要建立另一個？它只會給你一個更多的項目文件來維護，這打破了好的原則。
我在工作中憤怒地使用maven。這是一個苛刻的女主人。只要你做很多其他人擁有的東西，它就讓事情變得容易，只要你按照maven認爲你應該做的那樣做，這很重要。走出這條狹窄的道路，它會一路戰鬥。
我一直對BuildR留下深刻的印象。它可以像ANT一樣靈活使用maven的依賴系統。此外，它在孵化，所以它的邊緣有點粗糙。
我們完全按照您在我們的項目中所做的操作，並使用maven。你會想要使用maven有一個標準化的佈局和方式來建立你的項目。你永遠不需要將所有這些jar依賴關係存儲在SVN中，或者將它們保存在特殊的地方，maven可以爲你做這些。 Maven還可以幫助其他開發人員輕鬆理解您的項目。一旦你開始使用它，你永遠不會想回頭:)
Maven將會很適合你的項目IMO。 Maven是一個全能的構建和部署管理工具。最大的優勢在於，它使構建腳本比維護功能相當的Ant文件或shell腳本更加易於維護。
使用maven有很多好處，最重要的是它的約定優先於配置。這意味着如果你使用Maven目錄結構來佈局你的項目，那麼幾乎不需要配置它來構建和運行你的JUnit測試。
Maven給你的另一個重大勝利是依賴管理。您可以在Maven的配置文件中聲明性地定義項目的依賴項，稱爲項目對象模型（POM），Maven將所有的jar存儲在它所維護的本地目錄結構中。在公開可用的工件的情況下，罐子會自動從Maven中央存儲庫中下載，對於內部或專有的第三方罐子，您可以使用單個命令將它們安裝到存儲庫中。
除了只組織這些構件並自動設置構建類路徑以包含所有必需的jar之外，maven還將管理依賴關係層次結構。這意味着如果你的項目依賴於jar A，而依賴於jar B，那麼jar B將自動與你的WAR捆綁在一起，即使你沒有在構建配置中明確地將它列爲依賴項。
此外，從專業的開發角度來看，學習Maven是有道理的，因爲根據我的經驗，Maven已經超越了Ant作爲開源和專有Java項目中的合法構建工具。所有這些都說了，如果你有一個快速且可靠的構建系統，那麼爲了使用其他人所用的相同工具，將它轉換爲Maven可能並不值得。
Maven對於你想做的事情會很好。與大多數構建工具，Maven使用公約明智的（當然，比一般人至少更好），而且它有關於你提到的每一個領域「插件」：
Eclipse集成：m2eclipse
部署WAR文件：WAR plugin和Deploy plugin
Maven的也可以幫助你在Tomcat集成測試（如果你有一些），以後就可以開始使用cargo plugin停止或部署的戰爭。
無論如何，如果你打算在你的空閒時間看，這裏有一個免費的電子書（PDF格式）：Maven the definitive guide
希望它能幫助！
除了一個事實，即許多OSS項目的使用（或轉換爲）Maven和一些封閉源代碼的項目正在向Maven的時候，你的項目不一定從使用Maven受益很多。
但是，如果你會考慮開源它，那麼你的項目的用戶可能會受益於使用Maven的項目。
一些行家（依賴的JAR）的重要好處是可以和常春藤（http://ant.apache.org/ivy/）來了。
話又說回來，既然你似乎表明你是唯一的開發商。如果maven不適合你，你可以快速恢復。
BR，
〜一個
不要。看看還有什麼其他人saying，並仔細研究。另外請考慮看看我在SO上的其他一些關於Maven的評論。
我用於依賴管理Maven的前一段時間，因爲我累了將所有的罐子，如果我想測試它在另一臺電腦左右。你不需要爲此「學習」它，直到你學習它才花費很多時間。
但是最簡單的事情是隻問誰已經知道有人MVN，這樣他就可以告訴你它是如何工作，然後你瞭解它相當快。
我曾經開始使用Maven的新臨時工作。燒了2天試圖找出他們的Maven構建如何工作。原來他們都是在windows上使用maven 1.01，並且我無意中試圖在1.02版本上構建，所以它不適用於我。這個地方沒有人知道它是如何工作的，而且他們已經使用了好幾個月，他們對此感到滿意。幾個月後，在同一個項目中，我不得不深入研究果凍腳本來更改單個構建變量。這並不好玩。
當我第一次開始使用它時，我閱讀「convention over configuration」和「使用一組標準目錄」。這些都不是我能找到的文檔。我想你應該猜測。
我的意見：
總之，它幾乎是魔術，除非當它不起作用時，你可能不知道爲什麼。這似乎是一個不好的折衷。幾年前這是公平的。我知道我不友好，並且在後續版本中有所改進（我也使用了這些版本）。儘管如此，我討厭它（你能告訴嗎？）
Maven的一個強大優勢在於，它沒有編寫任何構建腳本或者甚至不必描述構建過程就可以完成很多構建/依賴管理。你已經有了你的項目設置，所以你不會從Maven爲你設置項目shell或者下載你指定的依賴關係而不必單獨下載它們。如果你的目標是學習如何使用和管理Maven，那麼對於沒有其他開發人員和構建過程的項目來說，這樣做是非常簡單的（從我所知道的情況來看）也無濟於事。所以我建議不要在現有項目中使用Maven。
然而，我會設置一個類似於你的使用Maven的簡單測試應用程序，並將其與您的項目結構進行比較，看看您是否遵循最佳實踐（至少在Maven開發人員看到它們時）以及您的應用程序是否遵循標準Web應用程序約定。
Maven的主要前提是「Convention over Configuration」，這意味着他們正在爲您做所有的工作，當且僅當您將自己提交給他們（通常並且容易生活）的約定範例。出於這個原因，將舊項目引入maven往往充滿了災難。 – 2009-01-02 17:03:25
@Spencer K：約定是個好主意。 maven的問題是它是近視和不靈活的。 – sblundy 2009-01-02 18:55:58