簡體   English   中英

如果我們已經擁有Eclipse,為什么我們需要Maven或Ant?

[英]Why do we need Maven or Ant, if we already have Eclipse?

我認為這個問題是比較IDE for IDE的擴展,我們還需要Ant嗎?

上面的問題有答案,但我想知道在Eclipse上使用Maven或Ant的具體示例。

當我在Eclipse中開發時,Eclipse會為我做所有事情,我只需要單擊運行按鈕。 而且,Eclipse可以讓您將代碼導出到可運行的jar甚至是.exe for windows。

所以我真的不知道為什么我需要Maven或Ant。

如果我確實需要, 我應該選擇哪一個,Maven還是Ant?

  1. 因為您的同事可能更喜歡NetBeans或IDEA
  2. 因為設置可能因eclipse安裝而異
  3. 因為您可能希望自動獲取依賴項
  4. 因為您希望自動完成整個構建:構建,jar,應用靜態代碼分析,運行單元測試,生成文檔,復制到某個目錄,根據環境調整某些屬性等。
  5. 因為一旦它自動化,您就可以使用持續集成系統,在每次更改或每小時構建應用程序,以確保所有內容仍然構建,測試仍然通過...
  6. 因為Maven使用約定優於配置。
  7. 因為您的IDE可能不支持您需要的一些奇特的代碼生成/轉換。
  8. 因為構建腳本記錄了構建過程。

Eclipse是一個開發環境。 但它不是構建工具。

我個人討厭Maven,但是YMMV。 有很多選擇:gradle,buildr等。

Maven讓我感到震驚,因為他們認為autoconf是領先的代碼自動化,並且不了解目標代碼需要對象環境。任何有效的開發或部署方式。 Ant很糟糕,但Maven結合了Ant和Ivy的所有最糟糕的功能。 它不會創建一個對象環境,並且它不適合使用它的工具。

簡單地說,對象環境應該具有所有類對象,即確定系統可用對象類型的對象,它們始終是可用的和可用的。 從那里我可以做任何我想做的事,實例化一個類的多個對象,設置各種序列和實例化規則等等。由於環境應該完全是實時的,我根本不需要構建工具。 在部署我的應用程序方面,環境簡單地拋棄構成我的應用程序的命名空間中從未被代碼引用的所有類對象並不困難。 JVM中的垃圾收集器今天在運行中幾乎完全相同。 那時我有一個由我的對象和我的對象引用的所有對象(主要是類對象)組成的部署環境,即我的應用程序和所有依賴項。 這就是虛擬機的工作方式。 (我們的虛擬機編寫得很糟糕,我們需要在另一台Linux虛擬機上的VMWare VM上的Linux虛擬機上運行Spring VM,這是軟件開發的另一個例子)。 當依賴關系得到更新時,它足夠簡單,環境可以提示開發人員將舊代碼合並到新庫中,使用新庫將代碼合並到舊版本,或保留兩個版本。 提示鼓勵開發人員進行稍微修改,有時需要避免每個庫有20個版本,而像Maven這樣的工具隱藏了這樣一個事實:你有20個版本並導致Java應用程序中常見的大量運行時膨脹。

在Java開發領域,Eclipse最接近於成為一個合適的對象環境,盡管有許多插件可以通過各種方式打破范式。 使用Maven的大多數原因在嚴格審查時都會崩潰。

Netbeans和Idea是誇張的文本編輯器,而不是對象環境,但是如果你確實想要將他們的工具用於成千上萬個Eclipse插件未涵蓋的東西,它們都可以導入和維護Eclipse項目,那么與開發人員相比,你的構建速度會非常慢使用Eclipse,但是,如果它們純粹是Netbeans或Idea項目,它們會很慢。

使用Maven不是一個嚴重的原因。

在Eclipse中導出/導入設置的難易程度(每個團隊在任何情況下都應該在任何IDE中執行此操作)使得不同的設置問題只不過是開發團隊的懶惰(或者空格與制表符的宗教爭論,大聲笑) 。

再次,不是使用Maven的嚴重理由。

團隊環境? 告訴我一個尚未使用GIT或SVN等存儲庫的團隊。 為什么我們需要通過設置Nexus repos來復制功能和維護問題?

那個人實際上是使用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的項目中,我已經看到了在Eclipse中沒有出現的瞬態Hudson / Jenkins錯誤,除非您已經安裝並正確配置了所有可能的M2E插件,並且大多數開發人員從未這樣做過。

似乎是避免Maven的另一個重要原因。

這並未涵蓋Maven的一些更基本的問題,例如它的命名空間破壞了Java命名空間和XML命名空間,它的構建單元(POM)與實際部署環境中的任何內容無關(想想它,當你分開時?通過的POM你有什么實際完成的成品沒有全部完成它是一種虛假的安全感,你已經分離問題和功能集成到所有運行作為一個整體的代碼)不同的共建單位; 手動維護復雜配置文件的麻煩,只有當您碰巧需要使用OSGi或其他容器並且必須維護影響Maven配置且受Maven配置影響的其他配置文件時才會變得更糟; 嘗試運行單元測試而沒有完整的代碼執行環境所導致的問題; 無數的版本不僅依賴但具體的Maven插件(其實我已經見過地獄JAR在Maven在多個Maven插件是使用依賴性沖突而建立本身 -的Maven的是應該解決的問題之一。

是的,您可以使用Maven構建目標代碼。 可以用C或甚至匯編程序編寫純對象代碼,但我不知道你為什么要這樣做。

避免Maven的最好理由是當你厭倦了上面提到的所有問題(以及許多其他沒有提到的問題)時,需要大量的工作去除一組項目。

繼承自C開發的思維方式,開發周期包括編寫代碼,編譯,匯編,構建,部署,測試,重做,在對象環境中無可救葯地過時。 在某些時候,我們需要告訴所有具有這種心態的人,他們需要重新學習如何發展,期間。 這樣做可以消除對Maven,Git和許多其他工具的需求,這些工具除了浪費時間外什么都不做。

對象開發應該在實時對象環境中完成,其中代碼更改在保存時進行測試,因為修改后的對象是實時的。 部署應包括從該環境中刪除僅開發人工制品,創建一個運行時,其中包含正在運行的應用程序在開發和測試中使用的所有內容。

我目前正在處理使用maven-assembly插件為OSGi應用程序創建部署程序集而導致的問題。 該應用程序在Eclipse環境中運行良好,它將所有代碼更改部署到環境中正在運行的OSGi容器中。 然而,盡管有一個非常好的配置/構建工程師,其唯一的工作就是完成該過程,但配置並不能通過maven-assembly過程完好無損。 如果我們擺脫了Maven(現在由於代碼量很大,但可能非常困難)並且使用了BNDTOOLS Eclipse插件,我們可以簡單地將Eclipse構建導出為Ant或Gradle無頭構建(注意,編寫BND的OSGi開發人員和BNDTOOLS 支持Maven,並且有充分的理由,Maven插件是由Felix開發人員編寫的,他們自己使用Netbeans和Maven,除了在部署周期結束時沒有實時環境),兩個工具都設置相同環境作為Eclipse,沒有僅供開發人員使用的GUI對象。 結果將是相同的配置和部署構建。 對於目前用於觀看慢速Maven或M2E構建的開發人員,每天可以輕松節省2-3小時,並釋放配置/構建工程師以在部署主機上對應用程序進行更多測試。

克服write / compile /匯編/構建/部署/測試的思維方式是唯一的主要障礙。 假裝你在1979 VT100終端而不是現代機器上進行編碼並不會讓你成為一個“真正的”開發者,它只是證明你的方法已經過時了35年。

在團隊中的開發人員中,其他人都沒有充分了解像Eclipse這樣的實時對象環境,足以讓它作為M2E和OSGi的實時環境工作,而且他們是頂級開發人員,他們只是沒有接觸過它流行的過時的命令行開發工具。 他們只是意識到,當我們進行結對編程以解決配置問題並且我正在共享我的屏幕時, 可能會這樣做,導致其他團隊成員之一驚呼“ 這就是你如何快速編寫代碼”,當他看到我的時候代碼更改立即在后台OSGi容器中測試自己。 我必須使用bash shell,例如當我查看遠程服務器上的日志時,事實上我確實這樣做非常有效,所以我可以盡快離開這個環境並返回到21世紀。

使用Ant或Maven有很多好處。

Maven或多或少是Ant的更新概念。 我決定采用另一種方法回答這個問題,而不是給你一個子彈點答案。 我會問你一個簡單的問題。 我假設你是一名開發人員; 或者有某種OO編程背景。

因此,如果您的經理要求您復制200個目錄,但忽略這些目錄中的jar, war and ear文件並復制一次。 然后,將這200個目錄部署到另一個目標,但只部署.class文件; 將其余文件復制到另一個目的地等。

為了你在java中這樣做; 它將是許多邏輯,大量代碼,不可擴展或適應變化。 因此,考慮到Ant或Maven將在運行中完成並准備所有這些,並且您的應用程序可以使用更少的開銷。 與Java相比,ant或Maven中代碼的大小將是1/4

點擊鏈接獲取更多技術優勢:

Maven的

螞蟻我找不到有益的真實答案,但我相信這會說服你;)

Maven和Ant用於編譯腳本,以便它們可以像Jenkins一樣在批處理作業中執行,也可以在命令行上執行。

事實上,Eclipse本身廣泛使用Ant來構建插件。

如果你要學習其中的一個,學習Maven,這幾天每個人都使用它(取代Ant)。

Maven通常用於為特定應用程序構建插件或jar。

假設您已經開發了一個應用程序,但您不想手動添加該應用程序所需的jar。 在這種情況下,Maven或Ant非常有幫助。 一旦你編寫了代碼,只需運行為 - > Maven Build(單擊Maven Build),它將生成所有必需的插件或jar並包含在應用程序庫build-path中。 懷疑應用程序將如何獲得這些jar,對於每個應用程序,都有一個名為POM.xml的xml文件,其中所有jar的引用都保存在那里以供下載。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM