問答專欄Q & A COLUMN
我們公司有幾個(gè)項(xiàng)目用過gradle，但大部分還是用maven，而且以后估計(jì)還會(huì)用maven，為什么呢？就是因?yàn)間radle的殺手锏：腳本太強(qiáng)大了。
早期的構(gòu)建都是腳本化的，用sh或者bat來組合編譯，打包，部署等過程，后來進(jìn)化到xml描述的ant工具，但還是可以寫很多自定義的任務(wù)，調(diào)用本地命令打包，各種任務(wù)組合，跟bat差不多，它們的共同特點(diǎn)就是：靈活！可以指定自己的依賴路徑，個(gè)性化打包過程。直到后來，maven出現(xiàn)了，只能通過不同的archtype來構(gòu)建不同的項(xiàng)目，而每種項(xiàng)目類型的項(xiàng)目工程目錄是固定的，如果沒有問題，一個(gè)package命令就可以了，不再有個(gè)性化的配置（自己寫mojo例外），約定優(yōu)于配置是它的哲學(xué)！而且，你只要理解pom.xml基本配置即可。
gradle結(jié)合了maven的優(yōu)點(diǎn)，同時(shí)又保留了腳本調(diào)用的特點(diǎn)，很多時(shí)候給人太多選擇和機(jī)會(huì)，反而會(huì)將項(xiàng)目（特別是大型項(xiàng)目）的構(gòu)建配置復(fù)雜化。導(dǎo)致新人很難掌握，其dsl語法是簡(jiǎn)化略的groovy調(diào)用，有時(shí)候不了解groovy語言及其語法，很難理解和寫出好的構(gòu)建腳本，學(xué)習(xí)成本高。
評(píng)論0
加載中...
第一到底是不是gradle比maven少，這個(gè)問題我沒看過數(shù)據(jù)不知道實(shí)際情況。但是從歷史角度和目前現(xiàn)狀來看maven日常接觸的是要多一些，畢竟技術(shù)這玩意就是一工具，用的熟練順手就好，沒必要一味求新。個(gè)人淺見
評(píng)論0
加載中...
用的多和少是量級(jí)上的。 gradle后于maven出現(xiàn)，顯然是挑戰(zhàn)者身份的。大多老項(xiàng)目是否愿意替換成gradle阻力很大。 所以量上看不那么能說明問題。
目前新項(xiàng)目是否一定選擇gradle？相信大家都沒定論?？梢奼radle作為繼任者的確沒有那么流行。 究其原因，可能有2點(diǎn)
1，配置表示語言問題。 項(xiàng)目表示類工具是一定要和項(xiàng)目解耦，因此注定了是個(gè)靜態(tài)配置。 maven用的老牌xml表示語言，雖然啰嗦，但是沒什么違和感，很容易理解。 反觀gradle為了簡(jiǎn)潔，失去了表示直觀性。
2，配置隔離原則。gradle用靈活腳本能力，不但增加理解維護(hù)成本，還打破了配置和實(shí)現(xiàn)的邊界。配置是黑盒子，隔離理解成本的，不應(yīng)該提供任何執(zhí)行和互操作能力。
這個(gè)是gradle的不好的地方，而減少構(gòu)建時(shí)間已經(jīng)不是關(guān)鍵改進(jìn)了。另外一個(gè)反例是sbt，用過的人相信都是一言難盡。
評(píng)論0
加載中...
我司有個(gè)項(xiàng)目用kotlin和java混寫的，gradle編譯，我從win換到mac，還是一直報(bào)gradle問題，最后我直接離職了。
評(píng)論0
加載中...
gradle現(xiàn)在是android studio的標(biāo)配構(gòu)建框架怎么說用得少呢？
android開發(fā)者目前烏泱烏泱一大片，而不會(huì)使用gradle基本沒法玩了，所以用的人很多的。
maven的使用者，主要還是是以前老的web開發(fā)者，雖然gradle強(qiáng)大得多，但由于學(xué)習(xí)成本的關(guān)系(gradle學(xué)習(xí)并不輕松)，很多人還在堅(jiān)持。
評(píng)論0
加載中...
Gradle 使用真的比 Maven 的人要少嗎？
Github 文件名搜索的參數(shù)數(shù)據(jù)：
圖1：是在 GitHub 中搜索 build.gradle 文件名的匹配數(shù)量有 970 萬
圖2：是在 GitHub 中搜索 pom.xml 文件名的匹配數(shù)量有 930 萬
當(dāng)然這一組數(shù)據(jù)僅僅只能作為參考，并不完全準(zhǔn)確，不過我們也能從中看出使用 Gradle 的人并不少，相反很多。
可能是題主身邊使用的比較少，造成這種原因可能主要原因有兩點(diǎn)。
相反對(duì)于熟悉 Gradle 的人來說，他們會(huì)更習(xí)慣 Gradle 的工作方式，因?yàn)樵谂渲蒙纤?Maven 要簡(jiǎn)潔。配置比 Maven 簡(jiǎn)潔這并不是 Gradle 最大的優(yōu)勢(shì)，而是 Automate Everything（自動(dòng)化一切） 實(shí)現(xiàn)上要比 Maven 容易的多，這才是我真正喜歡 Gradle 的理由。
比如：
根據(jù)環(huán)境自動(dòng)化配置，因?yàn)?*.gradle 文件其實(shí)就是 groovy 所以可以在構(gòu)建腳本中直接就是使用 groovy 編碼。不僅支持條件語句，還直接使用 java、groovy 的 API，比如 System.getenv 獲取系統(tǒng)環(huán)境變量然后根據(jù)值做一些操作就比 Maven 要容易很多。
repositories {
mavenLocal()
def aliyunEnabled = System.getenv("GITHUB_ACTIONS") == null
if (aliyunEnabled) {
maven {
url = "https://maven.aliyun.com/nexus/content/groups/public/"
}
}
mavenCentral()
}
在國內(nèi)訪問 Maven 的中央倉庫下載依賴效率不高，所以采用 Aliyun 提供的鏡像倉庫速度會(huì)快得多，但本人一直喜歡白漂 ???? 使用免費(fèi)的 GITHUB_ACTIONS，在 GITHUB_ACTIONS 構(gòu)建時(shí)訪問ucloud云鏡像速度很慢，所以就有了上一段邏輯。如果你使用 Maven 的話可能需要使用 profile 來區(qū)分，在構(gòu)建命令上加上 profile 相關(guān)的參數(shù)，或者使用 settings.xml 的方式去配置鏡像，但是多人協(xié)作時(shí)每個(gè)人都需要配置。而在使用 Gradle 時(shí)就可以輕易的做到一次配置到處運(yùn)行，不需要額外配置，不需要額外命令參數(shù)實(shí)現(xiàn)這一自動(dòng)化構(gòu)建。
更多的就不在舉例了，選擇一項(xiàng)工具，可能是客觀的原因，也可能是主觀原因。當(dāng)然我覺得更多的是在你身邊，團(tuán)隊(duì)有人帶頭去做這個(gè)事情。
同時(shí)也期望更多的人能使用 Gradle 來簡(jiǎn)化你的工作，讓工作變得更加輕松，Automate Everything。
評(píng)論0
加載中...
gradle大型項(xiàng)目配置比較好一點(diǎn)，簡(jiǎn)潔；
maven 相對(duì)來說比較冗余，但gradle還是基于maven 的，沒有多大的改變。習(xí)慣問題。
評(píng)論0
加載中...0
回答0
回答10
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答
