这是一个创建于 1860 天前的主题，其中的信息可能已经有所发展或是发生改变。
这两天在外面面试，面的是 Java 后端，会遇到一些风格迥异的程序员。 比如说 maven 会比 gradle 更好用，他们在 2019 年在推 maven。 比如说 TiDB 不够成熟，比起 hbase 来说，还没到生产环境的程度
想看一下大多数 Java 开发者的看法。我先来说。1. 会觉得用 markup language 写代码，怎么也比不上 groovy 这样的真正的程序语言 2. 我用过 Hbase，HBase 远没有它宣称的那样好，查询功能不多样，上了生产环节有不少运维的坑。下一次做大量数据的存储会考虑用 TiDB
你们怎么看这 2 个话题
第 1 条附言 · 2019-11-02 00:45:03 +08:00
多谢各位的看法，再补充几点我的想法
（其实是面试的时候不方便意志坚定地辩论，来和大家吐吐槽～
- 我其实也感觉 maven 和 gradle 选什么都一样，看项目传统。但是 2019 年推 maven 就有点不合适了吧，总感觉新技术才需要推。
- 关于 gradle 编译慢的。分类讨论，1 gradle wrapper 下载慢。确实慢，但这是网慢，不是编译速度慢。解决办法可是是某科学上网，修改 wrapper.properties 使用国内网址。maven 也有 wrapper，这 2 者也是等效的，好久没用了，不知道慢不慢。2 dependencies 下载慢，同样可以配 mirror url。
- maven 私服是 maven 和 gradle 都能用的，这个并没有对 2 个选项有影响。
- maven/gradle 配置复杂。感觉项目有一些额外定制都会产生臃肿的配置代码。但 maven 是 ml，看这么多标签名词感觉很累，而且他只有层级嵌套才能表达某种意思，要斜着看标签，累！ gradle 的语句看着就爽多了，有动词了。
（其实是面试的时候不方便意志坚定地辩论，来和大家吐吐槽～
- 我其实也感觉 maven 和 gradle 选什么都一样，看项目传统。但是 2019 年推 maven 就有点不合适了吧，总感觉新技术才需要推。
- 关于 gradle 编译慢的。分类讨论，1 gradle wrapper 下载慢。确实慢，但这是网慢，不是编译速度慢。解决办法可是是某科学上网，修改 wrapper.properties 使用国内网址。maven 也有 wrapper，这 2 者也是等效的，好久没用了，不知道慢不慢。2 dependencies 下载慢，同样可以配 mirror url。
- maven 私服是 maven 和 gradle 都能用的，这个并没有对 2 个选项有影响。
- maven/gradle 配置复杂。感觉项目有一些额外定制都会产生臃肿的配置代码。但 maven 是 ml，看这么多标签名词感觉很累，而且他只有层级嵌套才能表达某种意思，要斜着看标签，累！ gradle 的语句看着就爽多了，有动词了。
 |
1
GM 2019-11-01 12:14:22 +08:00
用惯了 maven，配置确实繁琐一些，但是不是很想换。
|
 |
2
srx1982 2019-11-01 12:18:27 +08:00
gradle 虽然语法简洁，但是总感觉构建很慢？
|
 |
3
johnniang 2019-11-01 12:19:13 +08:00 via Android
已经弃用 maven 好久了，gradle 第一次构建比较慢，后面会非常快。
|
 |
4
lxk11153 2019-11-01 12:19:27 +08:00
gradle 配置文件有什么格式化工具吗？
|
 |
5
zazalu 2019-11-01 12:24:44 +08:00 via Android  6
项目用什么就用什么 我没有选择权
|
 |
6
slyang5 2019-11-01 12:25:34 +08:00
gradle 有一定的学习成本 . 学会了,项目配置可以做的很灵活 优雅
|
 |
7
skypyb 2019-11-01 12:27:37 +08:00 via Android 1
就 maven 那 xml 配置，动不动几百上千行，看的不恶心么。
就一个构建工具而已，用谁都没差，我反正要用 gradle |
 |
8
aabbcc112233 2019-11-01 12:29:44 +08:00 via Android
maven 对比 gradle 就是个弟弟，毫无可比性。
|
 |
9
kran 2019-11-01 12:38:55 +08:00 via Android
都不喜欢，对比来看喜欢 maven 多一点，因为魔法少一点
|
 |
10
youngxhui 2019-11-01 12:44:46 +08:00
2019 了，一些主流的框架、库都会优先把 gradle 配置贴出来，之后才是 maven 配置
|
 |
11
dif 2019-11-01 12:49:54 +08:00
想用哪个用哪个。都能解决问题，有什么好争的？有这时间不如多写点 bug 了。
|
 |
12
f1ren2es 2019-11-01 13:02:20 +08:00
gradle + 1, 2019 年了为啥还要用 xml 这种反人类的格式？
|
 |
13
szq8014 2019-11-01 13:06:12 +08:00
自从新版 IDEA 对 maven 的支持变差以后觉得这两个好像用哪个都一样了。
HBase 是一个非常成熟且稳定的东西了，不过 HBase 做查询不是强项吧？ TiDB 只听过没用过。 |
 |
14
winterbells 2019-11-01 13:07:32 +08:00 via Android
idea 里 maven 的 xml 看起来都是一坨一坨的色块。。
|
 |
15
liuxey 2019-11-01 13:11:06 +08:00
两种我都不喜欢
|
 |
16
impl 2019-11-01 13:23:16 +08:00 via Android
2019 了，还有在用 Apache Ant 呢
|
 |
17
yuikns 2019-11-01 13:25:54 +08:00 1
只有我给 sbt 带坑里，一直觉得 sbt 最好用了么
|
 |
19
BigDogWang 2019-11-01 13:39:34 +08:00
用安卓的表示 gradle 在历史版本兼容上难用的跟狗一样。开发后台只用 maven 做简单的编译和依赖管理，很舒服
|
 |
20
zhazi 2019-11-01 13:45:42 +08:00 via Android
gradle 好，gradle 有学习成本，学 gradle 就要学 groovy，如果不学习用的不明不白的不如用 maven 了，起码没有一些黑魔法，为了学习一个构建工具学一门语言相对来说要求有点高。
接触过一些 android 同学只会 copy 配置。灵活构建没有得到体现。 如果全员都会 gradle 我也相信很少有人会用 maven。 |
 |
21
Jrue0011 2019-11-01 13:46:44 +08:00
额。。难道不是看做什么的吗？安卓大部分用 gradle，其他大部分用 maven
这个上 github 看看 build.gradle 和 pom.xml 都是哪些项目应该能看出来吧 |
 |
22
chendy 2019-11-01 13:47:19 +08:00
spring 程序员表示，没有从 maven 换到 gardle 的刚需
平时只有加依赖，升级依赖的时候回改一改 xml |
 |
23
assilzm 2019-11-01 13:48:16 +08:00 1
maven 和 gradle 都用过很长时间，相比之下 maven 更适用些，原因：
1、应用广，配置简单 2、出了问题一百度啥都有 gradle 的设想是非常好的，但是目前用起来的问题在于： 1、那个 DSL 很多人搞不明白，语法还很奇怪 2、版本跑的太快，新旧版本之间还有语法差异 3、eclispe 支持的非常不好，就连 IDEA，AS 也也有很多人反馈没有语法提示 |
 |
24
bccoder 2019-11-01 13:52:08 +08:00 via iPhone
gradle 也反人类，还不如直接用 java 写，搞一套 dsl 用起来也很诡异
|
 |
25
hoyixi 2019-11-01 13:53:42 +08:00 7
俩烂货，半斤八两
|
 |
26
qwerthhusn 2019-11-01 13:56:41 +08:00
我理解：管他 maven 还是 gradle，做一个项目只有很少的工夫花在这里，主要是业务。这里哪个顺手用哪个
|
 |
27
nicevar 2019-11-01 13:57:30 +08:00
服务端还是用 maven 比较舒服，安卓以前也用 ant，换成 gradle 差别也不大，gradle 的版本变化的坑真的很多
|
 |
28
kx5d62Jn1J9MjoXP 2019-11-01 14:01:42 +08:00
gradle 就是屎
|
 |
29
v2extroll 2019-11-01 14:04:55 +08:00
视情况看吧，工程级系统需要用 gradle，构建场景太多了，整个工程管理也比较复杂；但绝大部分业务系统实际并不需要 gradle，可选的话还是 maven 学习成本更低一点。
|
 |
30
6IbA2bj5ip3tK49j 2019-11-01 14:06:05 +08:00
个人之前用 maven
现在用 gradle kts，有了 kotlin，写 dsl 简单多了。 |
 |
31
Aresxue 2019-11-01 14:19:15 +08:00
maven 占主流，因为历史原因功能也确实更多样更强大，但 gradle 是趋势，作为去 xml 化中的一部分，毕竟标记型语法的配置看着既不够清爽还容易出问题。(但标记型语法在表达上可能还是更强大一些)
|
 |
32
mosesyou 2019-11-01 14:29:35 +08:00
1.maven 和 gradle 选择哪个并没有什么本质区别，目前也只是喜好问题而已
2.tidb 完全可以在生产上使用，在使用场景上，也和 hbase 不同 |
 |
33
jzmws 2019-11-01 14:41:16 +08:00
gradle 我感觉最好的是 加载本地的 jar 方便 / 不需要私有化库 直接放着文件夹下就可以引用了
|
 |
34
jjianwen68 2019-11-01 14:57:15 +08:00
构建工具而已，配置好了又不会经常改
|
 |
35
karottc 2019-11-01 15:00:19 +08:00
只用过 maven，没发现啥问题，感觉很好用
|
 |
37
fhsan 2019-11-01 15:23:29 +08:00
别问问就 gradle
|
 |
38
uleh 2019-11-01 15:27:22 +08:00
gradle 连个网要等死人……
|
 |
39
mikulch 2019-11-01 16:32:26 +08:00
学了一下 gradle 没学会，觉得还要学个新语言，就放弃掉了。继续 maven。
hbase query 本来不是什么强项吧，得考虑很多东西。设计 row key 什么的。 tidb 没用过。 |
 |
40
bigoktesk 2019-11-01 16:35:08 +08:00
gradle 并发编译多个应用的时候问题非常多
|
 |
42
crazycarry 2019-11-01 17:00:25 +08:00
说的你要写很复杂的 xml 一样的，垃圾 gradle，编译 es 折腾半天
|
|
43
crazycarry 2019-11-01 17:01:06 +08:00
已经 32 分了，还在编译
|
 |
44
Navee 2019-11-01 17:28:29 +08:00
maven 的理念挺好的啊，约定优于配置，没啥骚操作用起来真香
gradle 是给骚操作准备的，太骚容易翻车 |
 |
45
Raymon111111 2019-11-01 17:29:40 +08:00
工具是规范问题
你一个人独立干活可以选一选 大公司按照组织来 |
 |
46
dutianze 2019-11-01 19:01:47 +08:00
看不懂 gradle
|
 |
47
greatghoul 2019-11-01 19:07:18 +08:00
说的在理
|
 |
48
fewok 2019-11-01 19:32:11 +08:00
已经不想争这些事了，以后当 leader，我说用啥就用啥。
9102 年了，老古董们，咋不用 jdk6 了呢？？ |
 |
49
beetlerx 2019-11-01 19:51:13 +08:00
垃圾 gradle ，每次下载一大堆 wrapper, .gredle 目录好几 G
别人提 bug 也不改 https://issues.gradle.org/browse/GRADLE-3196  |
 |
50
doudouwu 2019-11-01 19:52:42 +08:00
@leonme
无一例外（略夸大，也差不多） 两者都有，则 maven 先 或者只有 maven 的 你说的情况不知道是不是我活在平行宇宙里 spring 官方的库，或者比较流行热门的库，大厂的库（阿里等） 大部分 README 里面也只贴 maven |
 |
51
encounter2017 2019-11-01 19:58:03 +08:00 1
@yuikns 你说的是 slow build tool 么（手动滑稽
|
 |
52
qiyuey 2019-11-01 21:55:30 +08:00
有 kts 之后还好一些，之前用着确实感觉不是很好用
|
 |
53
vjnjc OP @mosesyou #32 请问一同。使用场景上 hbase 和 tidb 不同，是指 hbase 只能按照某种线性条件查询，而 tidb 能够像 mysql 一样进行查询吗？（不好意思，可能问的不是很专业
|
 |
54
mxalbert1996 2019-11-02 01:00:07 +08:00 via Android
Gradle Kotlin DSL 才是未来，写起来比 Groovy 感觉好多了。
|
 |
55
sagaxu 2019-11-02 02:00:34 +08:00 via Android 1
我大概从 2017 年底迁移到了 gradle 上，但是 wrapper 是从来都不用的，每次 gradle 发新版我都跟上，永远只有最新一个版本。
groovy 很不熟悉，有时改点东西还要翻查语言文档，不过现在好了，都支持 kotlin script 了，去年我把所有 groovy 构建脚本全部换成了 kotlin script，转换的过程异常的曲折和艰难，现在官网文档例子是 kotlin 和 groovy 都有，当时可没有。 构建速度，跟 maven 是差不多的，mirror 配好阿里的，wrapper 禁用，几十万行代码的项目，全量编译一次一分钟多点，增量编译就很快了。 目前没遇到过非用 xx 不能实现的需求，但是 maven 版本要啰嗦好几倍，有些东西实现起来也要麻烦好多，毕竟一个是 xml，一个是现代编程语言。 |
 |
56
realpg 2019-11-02 09:29:24 +08:00
有没有人魔改一个不使用冗长的 xml 配置的 maven 甚至是个 maven xml configuration paser
|
 |
57
WhatIf 2019-11-02 09:30:04 +08:00
gradle 用的不多， 之前因为用 android studio 的缘故， 稍微接触了几次 gradle，当然之所以能接触就是因为坑。
所谓科学上网能解决， 这个问题当时并没能解决。 as 提示我说有新的版本 ，于是去升级， 升级以后告诉我 gradle 有新的，于是也去升级， 然后就卡死了。 首先墙不是问题， 因为根据无法下载的提示， 直接下载速度都很快。 反正也不知道到底是为了什么。 后来的做法是手工下载了文件， 然后根据日志找到目录位置， 替换以后才搞定。 一句话，还是不省心。 当然因为 gradle 用的不多 ， 所以其他坑怎么样就不知道了。 maven 在日常使用比较多， 还凑合，但是最大的坑还是下载的问题。 有时候，莫名下载了一般，文件被破坏。编译时候也能自己发现有问题， 然后居然不知道重新去下载， 逼着自己去目录里面删除文件才可以。 |
 |
58
uxstone 2019-11-02 09:43:35 +08:00
会用 gradle 的朋友, 没有说不香的 (滑稽)
|
 |
59
abcbuzhiming 2019-11-02 09:49:55 +08:00 1
maven 不算好用，但是推 gradle 这个，你们没发现对于一个严谨的依赖配置来说，gradle 这种用动态脚本建立的 DSL 自身就是个大问题吗？
还有 2019 年了，成熟一点，别动不动就“新技术应该推”，新技术不代表都 tm 好好吗，有些新技术其实是翔，背后有其它目的才推出来的，你也赶着去吃屎？ |
 |
61
youxiachai 2019-11-02 10:30:51 +08:00
@zhazi 现在 gradle 有 kts 了..可以用 kotlin 了..
|
 |
62
shanlan 2019-11-02 10:32:34 +08:00
上学的时候第一次用包管理工具，当时是学安卓。就一个 gradle 浪费了我很多时间和精力，最后看到这个东西就怕了。
后来学习 spring 的时候用上 maven，没有类似的烦恼了。 |
 |
63
qq6686496 2019-11-02 12:29:42 +08:00 via Android
都是垃圾
|
 |
64
Resource 2019-11-02 12:48:50 +08:00
很早的时候开始用 gradle，现在的语法变得我已经不太会用了
 |
 |
65
optional 2019-11-02 12:58:39 +08:00 via iPhone
构建工具而已，好一点差一点没有什么明显的区别。
hbase 不是这么用的。 |
 |
66
springmarker 2019-11-02 13:44:49 +08:00
Gradle wrapper 慢? 不是早就加上 CDN 了吗，我刚才还特地关闭了路由加速，速度凑凑的啊。
|
 |
67
bashbot 2019-11-02 14:15:34 +08:00
写代码的喜欢 gradle，做管理的喜欢 maven。
gradle 太灵活了，不利于团队协作和版本兼容。灵活往往意味着复用低和容易出妖蛾子，毕竟很难保证团队里每个成员的代码质量都很靠谱。 对于大项目和大团队，规范带来的收益通常比灵活 /先进带来的收益高。 |
|
68
uxstone 2019-11-02 15:47:19 +08:00
不理解也不喜欢 gradle 的 wrapper
明明就是一个构建工具, 没啥非要每个项目里都放一个 wrapper |
 |
69
kassadin 2019-11-02 17:01:53 +08:00
一个 XML， 一个 DSL，俩坑货。
|
 |
70
ErrorMan 2019-11-02 17:20:12 +08:00
XML 虽然啰嗦了点，但是比起 grandle 来说身为标记语言更严谨，个人倾向于 XML。规范一些维护的时候能省点心
|
 |
71
binbinyouliiii 2019-11-02 18:05:22 +08:00
|
 |
72
Cbdy 2019-11-02 18:29:27 +08:00 via Android
可以项目底下当一个 pom.xml ，再放一个 build.gradle。爱用哪个用哪个
|
|
74
sagaxu 2019-11-02 20:04:17 +08:00
@lxk11153 gradle 配置文件本身就是 groovy 或者 kotlin 代码，怎么格式化代码就怎么格式化配置文件
@f1ren2es 如果要自己做点工具，需要解析构建配置文件的时候，解析 XML 可比解析 DSL 简单多了 @doudouwu spring framework 早就迁移到 gradle 了，spring 团队已经迁移了 n 个库了 @nl101531 IDEA 的 gradle 补全也卡也慢 @springmarker CDN 去年开始才有的，之前下载可不快 @uxstone 我项目里都不用 wrapper，放弃兼容性，只支持当前新版 gradle maven 有一个巨大的优势，熟悉 gradle 的人往往也熟悉 maven 或者上手很快，反过来就不一定了 |
|
75
uxstone 2019-11-02 20:41:33 +08:00
@sagaxu IDEA 2019.2 以后的版本 在导入 gradle 项目时 会强制下载使用 wrapper。没有之前版本那样可以选择本地 gradle 的选项了
|
|
80
vjnjc OP @sagaxu #74 [maven 有一个巨大的优势，熟悉 gradle 的人往往也熟悉 maven 或者上手很快，反过来就不一定了
]。 真的没错，漏掉了这个优势！ |
|
83
mosesyou 2019-11-13 11:23:02 +08:00 1
@vjnjc tidb 更倾向于完全 oltp 的应用场景，hbase 更倾向于大数据量的密集写应用场景，读也是适合大数据量的读，而不是大范围的读
|
 |
84
yxlaisj 2019-11-29 15:10:43 +08:00
bullshet 就是一坨屎。作为构建工具，不熟悉的人编一个项目都各种报错
|
Select Language