关于 maven 和 gradle 使用比例的调查

[clifftts]

最近看一些 spring 的数据很多例子使用 gradle，但是目前我的项目基本上还是使用 maven，所有好奇到底要不要转用 gradle，网上很多对比 maven 和 gradle 的文章都是这样讲：Java 世界中主要有三大构建工具：Ant、Maven 和 Gradle。经过几年的发展，Ant 几乎销声匿迹、Maven 也日薄西山，而 Gradle 的发展则如日中天。 而且发现 V2EX 们很久以前就讨论过这个谁是王道的问题（ https://www.v2ex.com/t/255907 ），所以好奇大家现在到底用那个的多一些，大家亮出宝贝吧

我觉得大家可以顺带平时开发项目的类型，开发语言附带上，这样可以更多维度的比较 maven 和 gradle 的各自优势。
目前看 maven 对流程化单一打包方式很好满足，相对移动开发或者多样化打包 gradle 比较友好。欢迎大家各抒己见（吐槽 ）

[zouyyu]

gradle + groovy 灵活性太大了

[gam2046]

只是因为 Gradle 真的方便呀。而且干预编译流程也很简单。很容易定制化。

我现在手里有个项目（ Android ），就是魔改的很多地方了。

简单的比如输出的目标文件定制化，根据渠道不同输出不同文件名并直接上传到内网的服务器供测试、运营人员获取。

矫情的比如对于目标文件的签名文件不在项目中存在，在编译过程中鉴权，鉴权失败的只提供测试签名。

但是我感觉 maven 并没有日薄西山，只是两者的侧重点不太一样。

[murmur]

gradle 用的多不代表 maven 日薄西山
做为包管理 maven 还是很优秀的
尤其是对于早期自建 maven 库的公司
maven 的本身设计已经很优秀了 没有 npm 那种小文件硬伤

[yanaraika]

所有尝试专注某一方面的 DSL 最终都会发展成通用的编程语言。groovy 再坑也比在 XML 里搞出<if><else>好

[Cbdy]

手写 XML 配置是对 XML 的滥用

[clifftts]

@gam2046 感觉做移动开发的能感受到方便，我做 web 开发并没有感觉到那些优点

[hiveex]

目前接触到的几乎都是 maven

[clifftts]

@murmur 对的，maven 这点确实不错

[rockyou12]

@clifftts web 框架比较固定嘛，而且开发、发布流程本来也不太一样。

确实大部分项目 maven 已经可以解决了，但构建越复杂 gradle 的优势越明显。

maven 的<build></build>里写一堆插件再写个百来行配置，甚至要自己写插件的，gradle 可能几行就搞定了。

[clifftts]

@Cbdy 手写 xml 确实不好，spring 以前用 xml 做配置管理，用久了反倒觉得看项目的时候配置比较集中，一目了然，springboot 提倡 java config 配置倒是觉得 配置过于分散，零乱

[murmur]

@rockyou12 几百行不是个问题，因为 java 这种一个 spring 覆盖几乎整个后端的的特点，就算是再复杂的配置也是固化的定式，一个人写好了几代人抄就可以
哪里像前端隔三差五换一个构建工具

[clifftts]

@rockyou12 是的，我接触的 web 开发，目前没有遇到很复杂的项目构建，maven 插件已经满足了

[rockyou12]

maven 还有个不大不小的痛点，就是大项目中的子项目有同级依赖，比如 p2 依赖了 p1:
--project
|-p1
|-p2
|-p3
|-p4

但你只想打包 p2，也不想上传 p1，不编译其他项目。那只能用 mvn package -pl p2 -am，不能直接 cd p2 目录下去 mvn package。特别是在一个项目特别大，层级又很多很深，项目名字又长的时候，这个命令敲起来是非常……非常痛苦的……

gradle 依赖可以直接 cd 进项目再 gradle build，省心不少

[gam2046]

@clifftts 可能是这样的，Java Web 也有做，相对来说项目配置没那么多幺蛾子。

移动端比较多其实就是分渠道。不同渠道不同的依赖项、资源、应用名等等。基本上所有幺蛾子的基点都源于不同渠道造成的。

Web 项目相对来说会稳定得多。而且由于服务端相对可控，不像客户端发出去 再改的成本很高。

服务端的分渠道处理，更多的是在运行时期，而不在编译时期。而且服务端项目一般来说不会很在意程序体积，因此依赖项、资源，不管用不用都丢进去准没错。这样的策略在客户端是不能忍受的。

[rockyou12]

@murmur 别说了……给前端搞 ci 流程搞 npm install 的各种问题搞吐血过，还有之前用 go 也是 vendoer、vgo，maven 的依赖设计真的很优秀，基本没有踩过坑。

这些语言的依赖管理设计咋不搬过来用算了……搞这么多幺蛾子

[ipeony]

之前一直用 maven 的，gradle 用的少，主要是写着太灵活了，看着乱（还是 groovy 玩的不 6 ）。

后来写 kotlin，开始用 gradle.kts 。

最近写的项目尝试同时用 gradle 跟 maven （ maven 用 mvnw ）。

[honamx]

@rockyou12 install 过一次 p1 后, 会在本地仓生成 jar 包的, 你要是只打 p2 包, 完全可以再 p2 的目录下 package, 不需要管 p1 的吧

[loshine1992]

gradle 是趋势

[neoblackcap]

@rockyou12 golang 是因为 google 自家基础服务强劲，没看那 import 都是库的地址吗？全球分布式的单一代码仓库，你怕不怕？自家所有项目围绕 bazel 来搞，有什么不能构建，真是又简单又好。所以语言的基础服务才这么令人蛋疼。

你看同期的 Rust 就没有这么多幺蛾子，都是按照业界标准的来搞。

[skyuan]

公司项目用的 gradle，个人小项目用 maven。
总的来说，gradle 确实很方便，复杂项目可定制程度高，结合 groovy 简直强大到爆。
小项目用 maven 其实足够了，有特殊需求除外

[clifftts]

@skyuan 好奇，复杂项目复杂的点是什么，求赐教

[broadliyn]

这种构建工具，前期配置好基本到后期就不需要再去大改动了吧。。。。
所以感觉没有什么必要。

[zhazi]

gradle 好像升级过几次版本，各种版本兼容不太好，用着很累，也可能是没玩明白吧

[vjnjc]

有一次合作商提供了一堆 jar 文件给我，于是我就把 maven 编译的 spring boot 升级成了 gradle。。。

[aristotll]

都用

[ittianyu]

gradle 模块多了改动一下配置同步很慢，小项目还是用着很舒服。
maven 第一次很慢，全都要打成 jar 包。确实不够灵活，但后面修改依赖后不用同步，再次构建也快。

我是安卓转过来的，所以用 gradle 多一点。

[Cbdy]

@clifftts 代码写得清晰不清晰和语言实在关系不大。XML 分散、零乱起来比 Java 有过之而无不及

[jorneyr]

喜欢 Gradle，Gradle 定制不同环境下的配置比较方便，打包的时候过滤某些 jar 也很容易。

[kaito]

Gradle 出现较晚，所以有很多资料、教程不如 Maven 详细，另外大部分大一点的项目都有些年头了，所以 Maven 项目还比较多，我在学校学的就是 Gradle，语法也比 Maven 简洁，然而公司大部分用的 maven，推行 gradle 增加其他人的学习成本，既然都能解决问题，其实我都可以接受，如果是自己写东西玩玩，会用 gradle。

[specita]

公司一般都用 maven

[skyuan]

@clifftts 最常见的就是干预打包，做些前置校验什么的。我们其中一个项目就是会在打包的时候通过 groovy 生成检查一些依赖配置

[rockyou12]

@honamx install 可能导致多人开发的时候大家 install 的东西不一样。特别是 a 改了代码 b 不知道，没有再次 install，所以除非是单人开发，install 项目非常不好