我認爲這個問題是Compare to the IDE for Java,do we still need Ant?的擴展爲什麼我們需要Maven或Ant，如果我們已經有Eclipse？
上面的問題有答案，但我想知道在Eclipse上使用Maven或Ant的具體示例。
當我在Eclipse中開發時，Eclipse爲我做了一切，我只需要點擊運行按鈕。而且，Eclipse可以讓您將代碼導出到可運行的jar或甚至windows的.exe文件。
所以我真的不知道爲什麼我需要Maven或Ant。
而且，如果我確實需要，哪一個我應該選擇，Maven還是Ant？
Eclipse是一個開發環境。但它不是一個構建工具。
我個人討厭Maven，但是YMMV。有很多選擇：gradle，buildr等。
Maven和Ant用於構建腳本，以便它們可以像Jenkins或命令行一樣在批處理作業中執行。實際上，Eclipse本身使用Ant廣泛地構建插件。
如果您要學習其中的一種，請學習Maven，這是幾乎每個人現在使用的一種（取代Ant）。
gradle很流行，它現在在android studio – barlop
使用Ant或Maven有許多優點。
Maven或多或少是Ant的更新概念。 我決定採取另一種方法來回答這個問題，而不是給你一個重點答案。我會問你一個簡單的問題。我假設你會成爲一名開發人員;或者有某種OO編程背景。
因此，如果您的經理要求您複製兩百個目錄，但忽略這些目錄中的jar, war and ear文件並一旦複製。然後將這兩百個目錄部署到另一個目標，但只部署.class文件;將其餘的文件複製到另一個目的地等。
對於你在java中這樣做;它會有很多邏輯，很多代碼，並且不會被擴展或適應變化。因此，考慮到Ant或Maven將會爲您的應用程序使用更少的開銷而完成並準備好所有這些內容。與Java相比，ant或Maven中代碼的大小將爲1/4。
點擊鏈接，瞭解更多的技術優勢：
Ant我找不到同惠正宗的答案，但我敢肯定，這將說服你;）
Maven的罷工作爲一些過去他們銷售的c-shell腳本小子寫的東西，他們認爲autoconf是前沿代碼自動化，並且不瞭解目標代碼要求要求對象環境處於任何方式都有效f或開發或部署。螞蟻已經夠糟糕了，但Maven結合了Ant和Ivy的所有最糟糕的功能。它不會創建一個對象環境，並且它不適合使用它的工具。
簡而言之，對象環境應該包含所有類對象，即確定系統可用對象類型的對象，它們始終處於活動狀態並且可用。從那裏我可以做任何我想做的事情，實例化一個類的多個對象，設置各種序列和實例化規則等等。由於環境應該是完全活的，我不應該需要構建工具。在部署我的應用程序方面，環境並不難簡單地將構成我的應用程序的命名空間中的所有類代碼從未被代碼引用過。 JVM中的垃圾收集器在今天執行幾乎相同的事情。此時，我有一個由我的對象和我的對象引用的所有對象（主要是類對象）組成的部署環境，即我的應用程序和所有依賴項。這就是虛擬機的工作原理。 （我們的虛擬機寫得很差，我們需要在另一臺Linux虛擬機上的VMWare VM上的Linux VM上的Java VM上運行Spring VM，這是軟件開發白癡的另一個例子）。當依賴關係得到更新時，環境提示開發人員將舊代碼合併到新庫中，將新代碼合併到舊版本或保留兩個版本，這足夠簡單。提示鼓勵開發人員進行微小的修改，有時需要避免每個庫有二十個版本，而像Maven這樣的工具隱藏了您擁有二十個版本的事實，並導致Java應用程序中常見的大量運行時膨脹。
在Java開發領域，Eclipse最接近成爲適當的對象環境，儘管有許多插件以各種方式打破範例。當批判性地檢查時，使用Maven的大多數原因都會崩潰。 Netbeans和Idea是誇大的文本編輯器，而不是對象環境，但是如果您確實希望將他們的工具用於未被成千上萬個Eclipse插件覆蓋的內容，那麼這兩個工具都可以導入和維護Eclipse項目，您的構建只會非常不合理與使用Eclipse的開發人員相比較慢，但是，如果他們純粹是Netbeans或Idea項目，他們會很慢。
不是使用Maven的嚴重原因。
在Eclipse中輕鬆導出/導入設置（任何情況下，每個團隊都應該在任何IDE中執行的操作）使得不同的設置問題無非就是開發團隊的懶惰（或關於空間vs vs標籤，哈哈）。
同樣，使用Maven的原因不是很嚴重。
團隊環境？向我展示一個尚未使用GIT或SVN等存儲庫的團隊。爲什麼我們需要通過設置Nexus回購來複制功能和維護頭痛？
那其實是一個很好的理由不是要使用Maven。
運行服務器構建？現在，好主意不應該被代碼實際上檢入中的源代碼回購，而不是恰巧被推送到Nexus的隨機構建？這提出了一個反對Git的觀點，特別是Git和Maven。因爲在Git中，我不在分支上工作，在本地測試，然後提交（部分原因是由於Jenkins和Eclipse中Maven配置的差異，我的本地測試無法證明服務器構建工作），所以我必須將更改提交給一個不同的分支爲了看到服務器Maven構建失敗，然後提交進一步的修改來解決問題，導致repo中的源代碼不可讀。檢查代碼應該至少構建並通過單元測試，如果Git和Maven超出了圖片範圍，應該保證。
從Eclipse導出無頭構建是微不足道的 - 如果您真的關注它 - 只需要ant或Gradle，開發人員構建已由Eclipse維護，並且有幾個Eclipse jar（Eclipse將導出所有必需的文件以供無頭構建到目錄或zip文件，或者ftp到構建服務器）。像Hudson/Jenkins這樣的服務器構建工具可以從大多數源代碼倉庫中提取更新的代碼並調用任何構建腳本，因此不依賴於Maven。使用Maven，你可以強迫開發人員使用不適合任何人的工具，而是建立工程師（構建工程所需的時間更長，即使使用M2E也足以滿足這種需求），或者您也可以承擔服務器構建的可能性不起作用相當於像工作站構建，這是仍然如果你經歷了所有使用過多的M2E插件整合兩者的麻煩真的。無論哪種方式，你會得到一個更慢，更脆弱的工作站構建，以便同樣緩慢和更脆弱的服務器構建。在所有基於Maven的項目中，我已經看到了暫時的Hudson/Jenkins錯誤，除非您已經絕對安裝了可能的M2E插件並且正確配置，否則絕大多數開發人員都不會這樣做。
似乎是避免Maven的另一個重要原因。
這並不包括Maven的一些更基本的問題，比如它的命名空間打破了Java命名空間和XML命名空間，它的構建單元（POM）與實際部署環境中的任何東西都沒有任何關係（想想它，當你通過POM分離時，你在成品中實際完成了什麼？沒有什麼，它所完成的只是一種錯覺，你已經將關注點和功能分成不同的構建單元，所有運行作爲一個整體代碼塊）。手動維護複雜配置文件的麻煩，如果您碰巧需要使用OSGi或其他容器，並且必須維護其他配置文件，這些配置文件會影響Maven配置並受其影響，但這種配置文件很難理解;試圖運行單元測試而沒有完整的代碼執行環境所導致的問題;無數的版本不僅依賴關係，但具體的Maven插件（其實我已經見過地獄JAR在Maven構建本身在多個Maven插件是使用依賴性衝突 - 的Maven的是應該一個問題解決
是的，你可以用Maven構建目標代碼。你可以也寫在C或純粹的目標代碼，甚至彙編，但我不知道你爲什麼想要。
避免的Maven的最佳理由是工作的，當你生病的上面提到的所有問題（和許多其他未提及的）脫mavenize一組項目所需的數量驚人。
從C開發中繼承的開發週期包括編寫代碼，編譯，彙編，構建，部署，測試，再次完成的思維模式在對象環境中是絕望的過時的。在某個時刻，我們需要用這種心態告訴所有的人，他們需要重新學習如何發展，期間。這樣做可以消除對Maven，Git和其他大量工具的需求，這些工具只會浪費時間。
對象的發展應該在活動對象的環境中，因爲它被保存，因爲修改的對象是活的代碼變化進行測試來完成。部署應包括從該環境中僅刪除開發人工因素，創建一個運行時，其中包含開發和測試中運行的應用程序的所有內容。
我目前正在處理由使用Maven的組裝插件一個OSGi應用程序創建部署組件的一個問題。該應用程序在Eclipse環境中完美工作，該環境將所有代碼更改部署到環境中正在運行的OSGi容器中。然而，儘管擁有一個非常好的配置/構建工程師，但他們的唯一工作就是完成這個過程，但在Maven組裝過程中，配置不會完好無損。如果我們擺脫了Maven（由於代碼量很大，但是可能很困難），並且使用了BNDTOOLS Eclipse插件，我們可以簡單地將Eclipse構建版導出爲Ant或Gradle無頭版本（請注意，編寫BND的OSGi開發人員和BNDTOOLS 不支持Maven，並且出於很好的理由，Maven插件是由Felix開發人員編寫的，他們自己使用Netbeans和Maven，除了部署週期結束時沒有任何活動環境），其中兩個工具都已設置與Eclipse相同的環境，不包含僅供開發人員使用的GUI對象。結果將是一個相同的配置和部署構建。這樣每個開發人員每天可以節省2-3小時，每個開發人員目前都在觀看緩慢的Maven或M2E構建，然後釋放配置/構建工程師在部署主機上執行更多的應用程序測試。
克服編寫/編譯/彙編/構建/部署/測試的思想是唯一的主要障礙。假設你在1979年的VT100終端上編碼，而不是現代化的機器，這不會讓你成爲一個真正的開發者，它只是表明你的方法已經過時了35年。
在團隊中的開發人員中，其他人都沒有正確理解像Eclipse這樣的實時對象環境，以充分利用它作爲M2E和OSGi的實時環境工作，他們是頂級開發人員，他們只是沒有由於過時的命令行開發工具的普遍使用而暴露於此。他們只知道，原來是可能這樣做的時候，我們是結對編程解決配置問題和我分享我的畫面，引起了其他團隊成員之一驚呼「這你如何寫代碼，使該死的快」，當他看到我的代碼更改立即在後臺OSGi容器中測試自己。我可以在必要時使用bash shell，比如當我在遠程服務器上查看日誌時，實際上我可以非常高效地完成這項工作，以便儘快擺脫該環境，並返回到第21步世紀。
作爲一家前公司的實驗，在構建完成後，我們讓一個團隊繼續Maven構建，而另一個團隊使用Eclipse構建。 Maven構建每月保存建築工程師約30分鐘。然而，每個開發人員每天花費近3小時的時間，Maven的成本與Eclipse構建成本相當。 –
我們已經嘗試過這些工具，他們都比較麻煩，然後他們值得。我唯一的遺憾是，我只有一個投票給你。 – Vincent
「與使用Eclipse的開發人員相比，您的構建將會非常慢」證明或編輯 –
Maven通常用於構建特定應用程序的插件或罐子。
假設您開發了一個應用程序，但您不想去手動添加該應用程序所需的罐子。在這種情況下，Maven或Ant很有幫助。一旦你編寫了你的代碼，只需運行 - > Maven Build（點擊Maven Build），它將生成所有必需的插件或jar，幷包含在你的應用程序庫構建路徑中。有人會懷疑應用程序如何獲得這些jar包，對於每個應用程序，都有一個名爲POM.xml的xml文件，其中所有jar的引用都保存在那裏以用於下載目的。
你在一個團隊工作嗎？ –
貴公司決定他們希望每天凌晨2點進行自動生成。你想在那個時候開始工作來點擊IDE中的導出過程嗎？即使在週末？ –
我看到很多人使用Eclipse和Ant，而沒有問傑克遜問過這個非常重要的問題。去傑克遜的路！問題在於，大多數人/公司都在努力爭奪競爭對手，他們沒有時間學習可以幫助他們節省更多時間的工具和技術。 – Nav