Maven和Gradle,一箭雙鵰

幾年來,我一直很沮喪的基於java的構建工具項目。 在個人工做中,我看到幾個Java項目和模塊使用不一樣的構建系統。 值得慶幸的是,我所見過的大多數項目都是創建在過去一年Maven或Gradle。 根據這一趨勢,您只須要知道兩個不一樣的系統來了解項目的基本結構和依賴關係。 我不想給全部構建系統的概述,目前能夠用於定義構建的一個基於Java的項目,我認爲他們都很容易分裂成兩個不一樣的類型:

• 基於腳本的構建系統。
• 配置爲基礎構建系統。

目前,Maven和Gradle最著名的構建系統,他們每一個人的類型有關。 讓咱們有一個更深的看着他們兩人。

關於它

從個人觀點來看,它是一個基於腳本的構建系統。 對於這樣一個構建系統,您能夠定義您本身的基於命令或一個API的任務。 在它,你能夠編寫自定義構建任務很容易使用Groovy。 它提供了一些基本的插件爲共同構建Java項目的工做流程。 在此基礎上,你不須要定義任何任務,像Java的編譯爲每一個項目來源,一遍又一遍。 可是因爲它是基於任務,能夠很容易地構建腳本中定義的,你沒有任何結構或最佳實踐應該如何定義結構構建腳本和應該如何定義信息,如項目名稱或一個項目的依賴關係。 別誤會個人意思:它提供了良好的api,但它是由開發人員決定在構建腳本,例如,定義項目的依賴關係。 此外,你老是須要運行構建腳本獲得關於項目的信息。

對於Maven

Maven在基於腳本的構建工具的功能很是有限。 全部的項目信息和如何構建它必須指定pom.xml文件。 在內部,您能夠配置使用XML語法項目和構建。 全部的可能性,你必須配置項目的定義Maven在XSD文件。 經過這樣作,很容易定義的靜態元數據項目名稱或項目描述。 甚至技術信息像groupId,artifactId、版本或靜態依賴關係能夠很容易地定義的。 經過使用Maven構建工具,您的項目將被創建一個最佳實踐工做流程構建Java項目中定義的多個任務。 對於小項目來講這是能夠和api,可是若是你須要作一些特別的事情,你須要將插件添加到Maven。 這樣一個插件必須定義爲您的項目經過使用Maven的有限的XML語法。 這種插件必須的功能用Java編寫的並提供了一個罐子。 大而複雜的項目,你須要幾個永遠結束在一個大的這些項目和讀取XML文件做爲描述和構建您的項目的定義。

結論

一點,值得慶幸的是,這兩種方法的共同點是依賴性的方式將獲得解決。 Maven和Gradle將下載(傳遞)從任何構件庫的依賴關係。 Maven使用Maven中央這裏做爲默認Gradle用途JCenter。 此外,其餘存儲庫(如私人公司存儲庫)能夠很容易地定義的。 由於工件庫遵循一些共同的標準,全部提到的存儲庫能夠很容易地用於Maven或Gradle。

另外一方面,這兩個工具/構建系統有一些大的缺點在我看來。 很容易在Maven中定義項目元數據和依賴關係,但這絕對是可怕的建立高度定製的構建與Maven。 若是你想建立asciidoc-based文檔或上傳最終工件到Java EE服務器。 你的POM文件很快就會變得不可讀。 的Maven pom的Hazelcast項目例如,超過1000行。 理解一個1000行基於xml的新開發人員構建定義能夠是很是使人沮喪的。 因此,Maven是漂亮的小模塊和api,好比Apache commons或GSON。 開發人員能夠快速地瞭解項目及其依賴項只需看看POM文件。 此外,工具不須要運行構建流程/腳本獲取信息。 POM文件能夠被解析。

Gradle,另外一方面,提供了很大的靈活性。 由於它是基於一個腳本,你能夠作幾乎一切,並支持自定義比Maven構建步驟要容易得多。 這很好若是你想要部署到服務器或建立你的工件,例如,文檔。 但基於靈活性,構建腳本可能會變得複雜起來。 在大多數大型Java項目我已經看到在過去的幾年裏,只有少數開發人員知道如何改變它的構建。 此外,任何工具都須要運行Gradle構建項目的基本信息。 自從Gradle構建腳本是基於一種腳本語言,沒法解析。 因此,最後,Gradle可悲的不是用於構建Java項目的完美的解決方案。

在此基礎上,我想說,目前,沒有Java構建工具是全部基於Java項目的完美的解決方案。 Maven太有限但偉大的小型項目,按照定義的Maven生命週期和定義。 Gradle,另外一方面,能夠作你想作的一切,但甚至在其定義小型項目可能不一樣,由於結構/能夠定義您的構建描述以任何方式。 此外,您須要運行構建接收關於項目的信息。

基於這些觀點,我認爲,有一種方法的好處是簡單的總和。 當有一個看構建系統JavaScript,你能夠看到一個不一樣。 現代JavaScript構建系統狼吞虎嚥地吃、工做或多或少地喜歡它。 你能夠很容易地定義您本身的自定義任務基於腳本語言。 此外,元數據中定義的項目一般是一個單獨的文件中。 大多數項目,我看到過去的幾個月裏使用鮑爾定義項目的靜態元數據。 這包括項目的描述(名稱、描述、許可證等)及其依賴項。 構建工具像杯如今可使用鮑爾建造項目的信息(是的,這是一個很是簡單的描述的內部流程)。 在此基礎上,我問本身爲何Gradle,例如,不能作一樣的事情。 讓咱們考慮一個靜態定義Java項目和模塊,能夠很容易地集成到一個Gradle或Maven構建。 由於這樣的定義將使用這兩個工具都是開發人員輕鬆的學習如何閱讀和使用這樣一個靜態的定義。 此外,工具不須要任何外部過程開始,像一個構建腳本,得到關於Java項目的信息。 對於完整的項目,您能夠簡單地建立自定義Gradle內部任務獲得的全部信息的靜態定義和重用它真正的創建。

下面,我將嘗試素描這樣的靜態定義的樣子和它如何可使用。

定義一個靜態模塊描述

一個靜態模塊定義應該包含一個可讀的描述模塊。 這應該包括幾個參數:

• 模塊名稱
• 模塊描述
• 許可證
• url(回購問題跟蹤器、醫生等)。
• 開發人員信息(姓名、郵件等等)。

基於這個信息模塊描述可能看起來像這樣:

除了這些信息,一個項目須要一個唯一的標識符。 這能夠很容易地定義的groupId artifactId,因此靜態定義應該重用這些屬性:

定義一個特定版本的一個項目,versionId應該添加。 基於這些信息,提供的一切Maven中央或JCenter被定義的模塊。 此外,Maven pom。 xml能夠很容易地建立基於這些信息,能夠依賴這個模塊和其餘模塊。 後添加的屬性。 一個靜態項目定義可能看起來像這樣:

編譯Java模塊,咱們須要一些額外的信息。 我認爲最基本的信息是源編碼和應該用於編譯的Java版本。 在這裏,咱們須要指定一個Java版本定義所需的最低版本編譯的來源和定義的Java版本,編譯目標版本。 將這些信息添加到一個模塊的描述可能會在如下文件:

基於這些信息,一個項目,不須要額外的類類路徑中的下一個基本的Java類能夠很容易地進行編譯。 自完成模塊定義中提供了一個靜態方法,這能夠很容易地集成到任何支持IDE或構建工具。

因爲大多數項目取決於外部api和模塊,靜態模塊定義應該提供信息模塊的依賴關係。 像在Maven或Gradle,基於artifactId依賴項的定義,groupId,版本是最好的方法。 在編譯、構建工具或IDE能夠輕易下載從Maven中央或JCenter(傳遞)的依賴關係。 靜態項目定義主要應該提供全部功能的Maven依賴的定義,但在大多數用例,簡單地添加所需的依賴關係是全部你須要。 經過添加依賴關係信息,一個模塊的定義是這樣的:

ava模塊定義爲這樣一個靜態結構必須遵循的一些最佳實踐和基本規則,從Maven和Gradle-based是衆所周知的項目:

• 全部Java源必須被放置在src / main / Java。
• 全部資源,如圖片或配置文件,必須放置在src / main /資源。
• 全部Java源單元測試必須放置在src /測試/ Java。
• 單元測試的全部資源都必須放在src /測試/資源。
• 的靜態定義基於utf - 8的文件中定義的項目必須在項目的根文件夾。 該文件必須命名爲「元數據。
  jmm:(jmm表明Java模塊元數據)。

我爲何要用這個嗎?

大家大多數人已經在使用Maven這樣的構建工具,它,或者Ant來定義構建的Java項目。 我認爲這是好的,應該使用在將來,。 尤爲是當使用它,這是最新的構建工具所提到的,開發人員有這麼多可能要建立一個自定義構建文件,一般每一個構建做品以不一樣的方式,很難了解構建過程。 在全部這些文件中,關於構建過程的信息(好比一個構建腳本)和元數據的一個項目是混合。 經過封裝從構建的元數據,這將是更容易獲得一個模塊或一個構建的整體概述。 此外,每一個構建文件或腳本取決於使用的構建系統。 這意味着開發人員老是使用Maven常常不能讀或解釋Gradle構建腳本。 tool-independent方式經過定義元數據,任何Java項目的開發人員能夠理解的信息一旦他們至少有一個項目工做,提供靜態元數據。 元數據不只爲開發人員提供更好的可讀性,但構建工具能夠解釋元數據提供支持。 經過這樣作,全部的元數據文件的一部分的信息不該該被從新定義的構建腳本。 構建工具能夠直接使用元數據文件中的信息來構建項目。 Gradle文件經過這樣作,能夠構建一個JAR文件基於靜態元數據描述的模塊:

這將是足夠的編譯全部的項目來源,運行全部單元測試,並構建一個JAR,他的名字叫artifactId和版本建立的元數據文件。

旁邊的通用構建工具的ide能夠提供支持的靜態模塊的元數據。 在這種狀況下,您甚至不須要一個構建腳本。 基於的信息能夠在元數據中定義,IDE能夠下載所需的全部依賴項,編譯項目的來源,並運行全部單元測試。 而這僅僅是開始。 基於這種方法,它能夠掃描全部Java項目在GitHub,GitLab,BitBucket都找到一個模塊的使用。

提供一個圖形化的概述的傳遞依賴模塊將容易,。 而不是運行Gradle創建接收信息的依賴,任何工具能夠簡單地解析靜態元數據。 一個構建工具甚至沒有安裝。 構建工具和ide,其餘工具如構建服務器將受益於這種方法。

曾經最重要的工具支持靜態元數據,主要是全部Java項目的維護將變得更加容易。 方面喜歡定義的版本將只有一個焦點,和改變釋放的版本將會很容易。

方法的侷限性

靜態元數據並不適用於每一個項目。 一些項目須要在運行時生成的來源或動態依賴關係。 對於這類項目,靜態元數據可能不足以編譯項目。 但即便在這裏,這樣的元數據定義並非無用的。 可讀元數據能夠指定名稱或許可和非動態的全部依賴項,這些元數據文件的一部分,。 這將結束在須要構建文件的代碼,和工具,解釋靜態元數據至少能夠處理項目描述的一個子集。 是的,這種方法目前沒有可用的項目是基於另外一個編程語言,好比芬蘭灣的科特林或Groovy。 但隨着說:這只是一個初步的想法,我想要你的想法關於這個話題。