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