V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
clifftts
V2EX  ›  程序员

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

  •  
  •   clifftts · 2018-07-13 16:02:23 +08:00 · 10367 次点击
    这是一个创建于 2085 天前的主题,其中的信息可能已经有所发展或是发生改变。

    最近看一些 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 比较友好。欢迎大家各抒己见(吐槽 )
    32 条回复    2018-07-15 12:24:30 +08:00
    zouyyu
        1
    zouyyu  
       2018-07-13 16:06:18 +08:00
    gradle + groovy 灵活性太大了
    gam2046
        2
    gam2046  
       2018-07-13 16:09:58 +08:00   ❤️ 1
    只是因为 Gradle 真的方便呀。而且干预编译流程也很简单。很容易定制化。

    我现在手里有个项目( Android ),就是魔改的很多地方了。

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

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

    但是我感觉 maven 并没有日薄西山,只是两者的侧重点不太一样。
    murmur
        3
    murmur  
       2018-07-13 16:11:26 +08:00
    gradle 用的多不代表 maven 日薄西山
    做为包管理 maven 还是很优秀的
    尤其是对于早期自建 maven 库的公司
    maven 的本身设计已经很优秀了 没有 npm 那种小文件硬伤
    yanaraika
        4
    yanaraika  
       2018-07-13 16:12:58 +08:00 via Android
    所有尝试专注某一方面的 DSL 最终都会发展成通用的编程语言。groovy 再坑也比在 XML 里搞出<if><else>好
    Cbdy
        5
    Cbdy  
       2018-07-13 16:15:01 +08:00
    手写 XML 配置是对 XML 的滥用
    clifftts
        6
    clifftts  
    OP
       2018-07-13 16:27:38 +08:00
    @gam2046 感觉做移动开发的能感受到方便,我做 web 开发并没有感觉到那些优点
    hiveex
        7
    hiveex  
       2018-07-13 16:28:57 +08:00
    目前接触到的几乎都是 maven
    clifftts
        8
    clifftts  
    OP
       2018-07-13 16:30:00 +08:00
    @murmur 对的,maven 这点确实不错
    rockyou12
        9
    rockyou12  
       2018-07-13 16:31:11 +08:00
    @clifftts web 框架比较固定嘛,而且开发、发布流程本来也不太一样。

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

    maven 的<build></build>里写一堆插件再写个百来行配置,甚至要自己写插件的,gradle 可能几行就搞定了。
    clifftts
        10
    clifftts  
    OP
       2018-07-13 16:34:42 +08:00
    @Cbdy 手写 xml 确实不好,spring 以前用 xml 做配置管理,用久了反倒觉得看项目的时候配置比较集中,一目了然,springboot 提倡 java config 配置倒是觉得 配置过于分散,零乱
    murmur
        11
    murmur  
       2018-07-13 16:37:52 +08:00
    @rockyou12 几百行不是个问题,因为 java 这种一个 spring 覆盖几乎整个后端的的特点,就算是再复杂的配置也是固化的定式,一个人写好了几代人抄就可以
    哪里像前端隔三差五换一个构建工具
    clifftts
        12
    clifftts  
    OP
       2018-07-13 16:39:22 +08:00
    @rockyou12 是的,我接触的 web 开发,目前没有遇到很复杂的项目构建,maven 插件已经满足了
    rockyou12
        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,省心不少
    gam2046
        14
    gam2046  
       2018-07-13 16:40:26 +08:00
    @clifftts 可能是这样的,Java Web 也有做,相对来说项目配置没那么多幺蛾子。

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

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

    服务端的分渠道处理,更多的是在运行时期,而不在编译时期。而且服务端项目一般来说不会很在意程序体积,因此依赖项、资源,不管用不用都丢进去准没错。这样的策略在客户端是不能忍受的。
    rockyou12
        15
    rockyou12  
       2018-07-13 16:44:32 +08:00
    @murmur 别说了……给前端搞 ci 流程搞 npm install 的各种问题搞吐血过,还有之前用 go 也是 vendoer、vgo,maven 的依赖设计真的很优秀,基本没有踩过坑。

    这些语言的依赖管理设计咋不搬过来用算了……搞这么多幺蛾子
    ipeony
        16
    ipeony  
       2018-07-13 16:57:43 +08:00
    之前一直用 maven 的,gradle 用的少,主要是写着太灵活了,看着乱(还是 groovy 玩的不 6 )。

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

    最近写的项目尝试同时用 gradle 跟 maven ( maven 用 mvnw )。
    honamx
        17
    honamx  
       2018-07-13 17:09:29 +08:00
    @rockyou12 install 过一次 p1 后, 会在本地仓生成 jar 包的, 你要是只打 p2 包, 完全可以再 p2 的目录下 package, 不需要管 p1 的吧
    loshine1992
        18
    loshine1992  
       2018-07-13 17:24:21 +08:00
    gradle 是趋势
    neoblackcap
        19
    neoblackcap  
       2018-07-13 17:26:26 +08:00
    @rockyou12 golang 是因为 google 自家基础服务强劲,没看那 import 都是库的地址吗?全球分布式的单一代码仓库,你怕不怕?自家所有项目围绕 bazel 来搞,有什么不能构建,真是又简单又好。所以语言的基础服务才这么令人蛋疼。

    你看同期的 Rust 就没有这么多幺蛾子,都是按照业界标准的来搞。
    skyuan
        20
    skyuan  
       2018-07-13 17:27:18 +08:00
    公司项目用的 gradle,个人小项目用 maven。
    总的来说,gradle 确实很方便,复杂项目可定制程度高,结合 groovy 简直强大到爆。
    小项目用 maven 其实足够了,有特殊需求除外
    clifftts
        21
    clifftts  
    OP
       2018-07-13 17:29:35 +08:00
    @skyuan 好奇,复杂项目复杂的点是什么,求赐教
    broadliyn
        22
    broadliyn  
       2018-07-13 17:31:36 +08:00
    这种构建工具,前期配置好基本到后期就不需要再去大改动了吧。。。。
    所以感觉没有什么必要。
    zhazi
        23
    zhazi  
       2018-07-13 18:43:27 +08:00
    gradle 好像升级过几次版本,各种版本兼容不太好,用着很累,也可能是没玩明白吧
    vjnjc
        24
    vjnjc  
       2018-07-13 20:20:40 +08:00 via Android
    有一次合作商提供了一堆 jar 文件给我,于是我就把 maven 编译的 spring boot 升级成了 gradle。。。
    aristotll
        25
    aristotll  
       2018-07-13 21:38:30 +08:00
    都用
    ittianyu
        26
    ittianyu  
       2018-07-13 21:44:40 +08:00
    gradle 模块多了改动一下配置同步很慢,小项目还是用着很舒服。
    maven 第一次很慢,全都要打成 jar 包。确实不够灵活,但后面修改依赖后不用同步,再次构建也快。

    我是安卓转过来的,所以用 gradle 多一点。
    Cbdy
        27
    Cbdy  
       2018-07-13 21:45:51 +08:00 via Android
    @clifftts 代码写得清晰不清晰和语言实在关系不大。XML 分散、零乱起来比 Java 有过之而无不及
    jorneyr
        28
    jorneyr  
       2018-07-14 09:01:52 +08:00
    喜欢 Gradle,Gradle 定制不同环境下的配置比较方便,打包的时候过滤某些 jar 也很容易。
    kaito
        29
    kaito  
       2018-07-14 11:17:51 +08:00
    Gradle 出现较晚,所以有很多资料、教程不如 Maven 详细,另外大部分大一点的项目都有些年头了,所以 Maven 项目还比较多,我在学校学的就是 Gradle,语法也比 Maven 简洁,然而公司大部分用的 maven,推行 gradle 增加其他人的学习成本,既然都能解决问题,其实我都可以接受,如果是自己写东西玩玩,会用 gradle。
    specita
        30
    specita  
       2018-07-14 16:04:33 +08:00
    公司一般都用 maven
    skyuan
        31
    skyuan  
       2018-07-15 12:22:50 +08:00
    @clifftts 最常见的就是干预打包,做些前置校验什么的。我们其中一个项目就是会在打包的时候通过 groovy 生成检查一些依赖配置
    rockyou12
        32
    rockyou12  
       2018-07-15 12:24:30 +08:00
    @honamx install 可能导致多人开发的时候大家 install 的东西不一样。特别是 a 改了代码 b 不知道,没有再次 install,所以除非是单人开发,install 项目非常不好
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5932 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 02:36 · PVG 10:36 · LAX 19:36 · JFK 22:36
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.