最近看一些 spring 的数据很多例子使用 gradle，但是目前我的项目基本上还是使用 maven，所有好奇到底要不要转用 gradle，网上很多对比 maven 和 gradle 的文章都是这样讲：Java 世界中主要有三大构建工具：Ant、Maven 和 Gradle。经过几年的发展，Ant 几乎销声匿迹、Maven 也日薄西山，而 Gradle 的发展则如日中天。 而且发现 V2EX 们很久以前就讨论过这个谁是王道的问题（ t/255907 ），所以好奇大家现在到底用那个的多一些，大家亮出宝贝吧
请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 2867 days ago, the information mentioned may be changed or developed.
Supplement 1 Jul 14, 2018
我觉得大家可以顺带平时开发项目的类型，开发语言附带上，这样可以更多维度的比较 maven 和 gradle 的各自优势。
目前看 maven 对流程化单一打包方式很好满足，相对移动开发或者多样化打包 gradle 比较友好。欢迎大家各抒己见（吐槽 ）
目前看 maven 对流程化单一打包方式很好满足，相对移动开发或者多样化打包 gradle 比较友好。欢迎大家各抒己见（吐槽 ）
 | 1 zouyyu Jul 13, 2018 gradle + groovy 灵活性太大了 |
 | 2 ntdll Jul 13, 2018  1 只是因为 Gradle 真的方便呀。而且干预编译流程也很简单。很容易定制化。 我现在手里有个项目（ Android ），就是魔改的很多地方了。 简单的比如输出的目标文件定制化，根据渠道不同输出不同文件名并直接上传到内网的服务器供测试、运营人员获取。 矫情的比如对于目标文件的签名文件不在项目中存在，在编译过程中鉴权，鉴权失败的只提供测试签名。 但是我感觉 maven 并没有日薄西山，只是两者的侧重点不太一样。 |
 | 3 murmur Jul 13, 2018 gradle 用的多不代表 maven 日薄西山 做为包管理 maven 还是很优秀的 尤其是对于早期自建 maven 库的公司 maven 的本身设计已经很优秀了 没有 npm 那种小文件硬伤 |
 | 4 yanaraika Jul 13, 2018 via Android 所有尝试专注某一方面的 DSL 最终都会发展成通用的编程语言。groovy 再坑也比在 XML 里搞出<if><else>好 |
 | 5 Cbdy Jul 13, 2018 手写 XML 配置是对 XML 的滥用 |
 | 7 hiveex Jul 13, 2018 目前接触到的几乎都是 maven |
 | 9 rockyou12 Jul 13, 2018 @clifftts web 框架比较固定嘛，而且开发、发布流程本来也不太一样。 确实大部分项目 maven 已经可以解决了，但构建越复杂 gradle 的优势越明显。 maven 的<build></build>里写一堆插件再写个百来行配置，甚至要自己写插件的，gradle 可能几行就搞定了。 |
 | 10 clifftts OP @Cbdy 手写 xml 确实不好，spring 以前用 xml 做配置管理，用久了反倒觉得看项目的时候配置比较集中，一目了然，springboot 提倡 java config 配置倒是觉得 配置过于分散，零乱 |
| 11 murmur Jul 13, 2018 @rockyou12 几百行不是个问题，因为 java 这种一个 spring 覆盖几乎整个后端的的特点，就算是再复杂的配置也是固化的定式，一个人写好了几代人抄就可以 哪里像前端隔三差五换一个构建工具 |
| 13 rockyou12 Jul 13, 2018 maven 还有个不大不小的痛点，就是大项目中的子项目有同级依赖，比如 p2 依赖了 p1: --project |-p1 |-p2 |-p3 |-p4 但你只想打包 p2，也不想上传 p1，不编译其他项目。那只能用 mvn package -pl p2 -am，不能直接 cd p2 目录下去 mvn package。特别是在一个项目特别大，层级又很多很深，项目名字又长的时候，这个命令敲起来是非常……非常痛苦的…… gradle 依赖可以直接 cd 进项目再 gradle build，省心不少 |
| 14 ntdll Jul 13, 2018 @clifftts 可能是这样的，Java Web 也有做，相对来说项目配置没那么多幺蛾子。 移动端比较多其实就是分渠道。不同渠道不同的依赖项、资源、应用名等等。基本上所有幺蛾子的基点都源于不同渠道造成的。 Web 项目相对来说会稳定得多。而且由于服务端相对可控，不像客户端发出去 再改的成本很高。 服务端的分渠道处理，更多的是在运行时期，而不在编译时期。而且服务端项目一般来说不会很在意程序体积，因此依赖项、资源，不管用不用都丢进去准没错。这样的策略在客户端是不能忍受的。 |
| 15 rockyou12 Jul 13, 2018 @murmur 别说了……给前端搞 ci 流程搞 npm install 的各种问题搞吐血过，还有之前用 go 也是 vendoer、vgo，maven 的依赖设计真的很优秀，基本没有踩过坑。 这些语言的依赖管理设计咋不搬过来用算了……搞这么多幺蛾子 |
 | 16 ipeony Jul 13, 2018 之前一直用 maven 的，gradle 用的少，主要是写着太灵活了，看着乱（还是 groovy 玩的不 6 ）。 后来写 kotlin，开始用 gradle.kts 。 最近写的项目尝试同时用 gradle 跟 maven （ maven 用 mvnw ）。 |
 | 17 honamx Jul 13, 2018 @rockyou12 install 过一次 p1 后, 会在本地仓生成 jar 包的, 你要是只打 p2 包, 完全可以再 p2 的目录下 package, 不需要管 p1 的吧 |
 | 18 loshine1992 Jul 13, 2018 gradle 是趋势 |
 | 19 neoblackcap Jul 13, 2018 @rockyou12 golang 是因为 google 自家基础服务强劲，没看那 import 都是库的地址吗？全球分布式的单一代码仓库，你怕不怕？自家所有项目围绕 bazel 来搞，有什么不能构建，真是又简单又好。所以语言的基础服务才这么令人蛋疼。 你看同期的 Rust 就没有这么多幺蛾子，都是按照业界标准的来搞。 |
 | 20 skyuan Jul 13, 2018 公司项目用的 gradle，个人小项目用 maven。 总的来说，gradle 确实很方便，复杂项目可定制程度高，结合 groovy 简直强大到爆。 小项目用 maven 其实足够了，有特殊需求除外 |
 | 22 broadliyn Jul 13, 2018 这种构建工具，前期配置好基本到后期就不需要再去大改动了吧。。。。 所以感觉没有什么必要。 |
 | 23 zhazi Jul 13, 2018 gradle 好像升级过几次版本，各种版本兼容不太好，用着很累，也可能是没玩明白吧 |
 | 24 vjnjc Jul 13, 2018 via Android 有一次合作商提供了一堆 jar 文件给我，于是我就把 maven 编译的 spring boot 升级成了 gradle。。。 |
 | 25 aristotll Jul 13, 2018 都用 |
 | 26 ittianyu Jul 13, 2018 gradle 模块多了改动一下配置同步很慢，小项目还是用着很舒服。 maven 第一次很慢，全都要打成 jar 包。确实不够灵活，但后面修改依赖后不用同步，再次构建也快。 我是安卓转过来的，所以用 gradle 多一点。 |
 | 28 jorneyr Jul 14, 2018 喜欢 Gradle，Gradle 定制不同环境下的配置比较方便，打包的时候过滤某些 jar 也很容易。 |
 | 29 kaito Jul 14, 2018 Gradle 出现较晚，所以有很多资料、教程不如 Maven 详细，另外大部分大一点的项目都有些年头了，所以 Maven 项目还比较多，我在学校学的就是 Gradle，语法也比 Maven 简洁，然而公司大部分用的 maven，推行 gradle 增加其他人的学习成本，既然都能解决问题，其实我都可以接受，如果是自己写东西玩玩，会用 gradle。 |
 | 30 specita Jul 14, 2018 公司一般都用 maven |
Select Language