Java專案建置工具的選擇 @ AKIRA 璋の隨寫

最近在評估單位內部的Java專案建置工具，主要的評估對象是Maven & Gradle，基本上是大方向的評估，還沒有深入到技術細節上的差異。以目前在網上查到的資料來看，絕大多數都是推薦使用Gradle，這點也是很有趣，和Maven的高市佔完全相反，想看其他的反面意見，可能還得另外下關鍵字才搜的到。

這篇主要介紹Maven/Gradle的一些特性，和從幾個不同角度來看Maven or Gradle的選擇，但基本上這題沒有標準答案，主要還是取決於人、組織、專案特性、還有個人偏好。

建置工具歷史沿革

Maven長期以來一直是預設的Java組建工具，主要原因是他標準化的組建程序與結構。但Gradle在過去幾年越來越受歡迎，最大的原因可能是其組建腳本的簡潔特性。
Maven試圖解決Ant過於靈活、沒有幫助開發者管理依賴項目的缺點。改以「約定而非配置」的理念，並集中管理相依性，讓開發者在最短時間內了解專案組建的完整狀況。
Gradle認為Maven的組建程序沒有彈性，過度主觀，故根據Ant & Maven的概念，並使用基於Groovy領域特定語言來宣告專案組態，以編寫自訂且複雜的組建邏輯。

特性說明

評估比較

這部分我認為大略可以從幾個角度著手：

市佔率/成熟度：高市佔/成熟度意味著更豐富的外掛資源，較低的問題解決成本，從這點來看，Maven相對成熟，版更頻率亦較低。另參考Datanyze的資料(2020/5/9)，Maven市佔率遠高於Gradle（55.16% vs 4.28%），其實這麼大的落差我是有點懷疑的，不確定這個網站背後的統計數字根據是什麼。

學習成本：XML vs Groovy，基本上對大多數組織而言，Groovy語言很可能是額外的學習成本，這點也和組織人員的能力有關。
CI工具整合：兩者皆可與現行主流CI工具整合，例如Jenkins。
外掛資源：Maven > Gradle。但另一個角度是或許在Maven中需要使用外掛的狀況，在Gradle卻不需要。
專案適用性：思考是否會有組織內部既有專案不適用的狀況。
轉換成本：針對組織現行的Legacy專案，從舊的建置工具轉換的成本（例如Ant），主要的成本我認為在於專案結構標準化與第三方Library相依性管理。
IDE整合程度：以Eclipse來說內建支援Maven，而Gradle似乎得另外使用plugin。
標準化 vs 彈性（靈活性）的取捨：工具的靈活性也往往導致不易標準化的問題，這點的重要性就和組織特性有關了。
建置效能：依據Gradle官方資料，Gradle在建置效能上是高於Maven的。這點的重要性也是取決於組織內部的專案特性，對許多單位的一般專案而言，我認為影響應該大多不大。

除了上述幾項，我想還可以再從幾個角度來評估：

Gradle想改善的Maven缺點，是否是組織實際遭遇的痛點：每個新技術通常都是為了解決舊技術的某些缺點，但也往往會帶來另外的問題，故並無絕對的優劣問題，只有適用性的問題。
Maven <-> Gradle的轉換成本：假設今天選擇Maven，從最糟的狀況來看，若最後實務上發現有不得不改為使用Gradle的理由，此時的可行性與成本為何，以此例Maven轉換為Gradle來看，初步看起來可行性與成本亦不高，主因在於：
- Gradle遵循許多與Maven相同的約定，例如程式碼標準專案結構、Library的管理同樣都支援Maven Repository 。
- 建置設定檔的轉換有現成工具支援。

建置工具的選擇考量（參考資料：持續交付使用Java）

Ant + Ivy