有多少人还在用 Maven 构建项目？

[diagnostics]

最近用 maven 有些槽点(当然也可能是我自己对 maven 的学习也不够深入), 我既写 java 也写 scala, 有人在 scala 帖子诟病的 sbt 难用，相比之下 maven 才是真的“难用”。

我说的难用不是指难安装、简单打包，而是带一些场景：

1. xml 问题

xml 可读性某些层面太差了，过于繁琐，对版本管理，子模块管理全部揉杂在一起

2. 子模块管理问题

我们的项目组开发是一个 framework 的，也就是自身需要维护一大堆依赖，被别人引用的时候也会带上这些依赖的版本。

我们尝试过像 spring 那样用:

• project：只作为根入口
• dependencies：管理所有依赖，包括自身子模块的依赖，相当于 BOM
• parent：其他子模块的父项目，用于预定义一些构建（ spotless 、spotbugs 等）

但是 IDEA 的识别不够好，总是出现某些子模块的版本找不到（ IDEA 无法识别到这些子模块就是我维护的，而不是第三方库，而是反过来，总是去远仓库下载而不是项目的 target 上查找）

后面我们直接用 root 管理所有的 dependenices ，还是有问题，但是遇到问题只能本地 install 一下

3. CICD 编写问题

我们用的是 Gitlab CI/CD ，由于模块太多，一个 mvn test 运行太慢了，等个 CI 的功夫能干很多事情，但是我们尽可能希望快一点验证 commit ，继续做后续的测试，所以我们搞了按模块区分的单测：例如 coreTest 、serverTest 、extensionTest 等。。。

maven 可以用 mvn test -pl core -pl server 这样解决，但是部分 extension 模块是依赖 server 或者 core 的，就只能用 mvn test -pl extension -am also make 依赖，这样的后果就是跑 extension 的时候，把 core 的单测也跑了（这还加速啥，依赖多的项目，很大概率直接跑个完整的 test ）。 这个问题，我们后面用 profiles 解决了，但是维护起来太鸡巴蛋疼，太繁琐了（重构的时候）

4. 构建 Task 诊断问题

我改造 CICD 的时候，希望能利用上缓存机制，多个 task 来加速，但是我发现 compile 的时候也会把 validate 阶段的 enforce 插件也给跑了... 问题是，我看了下好像没有命令来看执行 xx 的时候会同时执行什么，只能跑一下 xx 然后看。。。

结论

可能我用 maven 的姿势不太对，但是越深入就越感觉这玩意不适合复杂项目，就适合简单做个：

clean 、test 、package 、install 、deploy

怀念 sbt...(尝试过 gradle 、迁移看了半天，需要考虑点有点多，还没正式打算改过去，改过去也不知道好不好）

ps：写 Java 的人里可能有大神，但是只写 Java ，写久了真的会降智（不思考合理性，不愿意接受其他，是的，我说的是我自己）

除了 gradle 没有其他工具吗？ ant 、sbt 、bazel ？ 都说 gradle 不好，没几个说 gradle 为什么不好，没几个能回答我提出的问题

看完回复，大部分人都是 CRUD Boy ，压根都没有 framework 、大项目的开发经验，基本上就是创建项目之后，就算有子模块，都是固定的 dao, service, controller, application 或者 library. application 这种简单架构。

有人还觉得我们架构设计有问题，试问，我们对外提供 spring starter 集成，现有需求接入 Jedis 实现（原本是 lettuce ）那么我们可以选择两种方案：

- 增加一个 lettuce-starter
- 设计开始之初就有一个 redis-starter 里面实现各种例如 lettuce 、jedis 实现

还有就是，假如我们是原来有 kafka 作为 source 实现，现在增加一个 http 、grpc 呢？又来到十字路口

我看了下回帖的，95% 的开发，做过 https://github.com/alibaba/jetcache/tree/master/jetcache-support 这个项目级别都没有。

看起来大家工作压力都挺大的，戾气那么重。

我看回帖确实挺不爽的，也回怼了很多，因为我正常讨论，大家都随便回回。

例如：Maven 这么流行就有它的道理，他就是最好的。那么 Nokia 在 iPhone 发布后，是不是最好的手机呢？

我没有像其他帖子一样，自己用得不对就骂某个框架，工具。我也提出我自己可能确实用的不对，有人能给我意见，看起来不到一个手的人手，剩下的都是：

- 你对 Maven 学得不够深
- 不用 Maven 用啥？
- 其他太难学了，我不想学

可能和我帖子标题有关系？

匿名提交了 maven 仓库，解释了一下，看不懂的话执行一下命令： https://github.com/d789a08a-66a8298fd305/maven-issue

[Ayanokouji]

比 maven 好用的包依赖工具还真没几个。
你可以试下 golang/node/python 的包管理。
gradle 很强大，但是你得熟悉。
我觉得比 maven 好用的也就 rust 的了吧。

ps：maven 的 pom 文件也有姿势可以不用 xml 。https://github.com/takari/polyglot-maven

[jatesun]

现在主流的还是 maven 吧。maven 感觉蛮好用的。

[alwaysonlinenet]

不用 maven 用啥

[mango88]

当然也可能是我自己对 maven 的学习也不够深入

---

自信点，把 “可能” 去掉

[Yukineko]

关键是,假如不用 maven,那还能用啥?

[zhenjiachen]

早就换 gradle 了，为什么我的感觉和你相反，maven 简单，快，但是不灵活，gradle 学习难，慢，但是灵活。gradle 学会了慢一点也能忍了。

[codingmiao]

用了 gradle 才知道 maven 的好。一次配置到处运行，gradle 是很灵活，但是别人用还得提心吊胆版本不兼容之类的问题，一个构建工具要花那么多心力去维护真的累。

[perfectlife]

java 多模块项目本身就头大，cicd 比较恶心，我个人是不太喜欢一堆项目在一个仓库下，当前比这个更恶心的是前端的 monorepo

[zliea]

cicd 的工具是依赖 cicd 的配置，如果依赖 maven ，一般上需要一个集成 cicd 的插件。

[fanxasy]

其实 maven 是真好用，很多问题在如今强大的 IDE 加持下也不足为道了

[zliea]

理论上顺序应该 cicd 工具先读取工程里 cicd 的配置，然后 cicd 的某一步调用 mvn 进行构建。如果做的完整的话，mvn 的增加 cicd 插件反向通知 cicd mvn 构建结果。

[caliburn1994]

gradle 学习曲线高。没这个必要

[4ra1n]

我还是不习惯 gradle 新项目都用 maven 来做

gradle 可能确实灵活先进，但要学 groovy 语言，面临新旧版本不兼容问题

maven 只要网络没问题，我很少遇到别人的项目我无法编译的问题

[yusheng88]

Java 项目基本都是在用 maven

1 、xml 问题
xml 是通俗易懂，一目了然，但依赖多了，看着啰嗦 [重复字符太多] 。
gradle 需要你知道依赖配置写法，单纯看配置文件，是没有 xml 的更傻瓜式的 [没系统学习过的，同时看 pom.xml 和 build.gradle 文件，肯定是 pom.xml 更加容易理解] 。

2 、子模块管理问题
maven 的依赖管理规则一直都很清晰，可以自己去看下加载优先级。
我参与的项目，就算是多模块||微服务项目，也没觉得 maven 依赖有什么问题， 也不存在 idea 识别不好问题，不清楚你是什么情况。
复杂项目一般有自己的 maven 仓库[nexus]，不需要本地 instasll

3. cicd
用的是 jenkins 实现，简单易用，不知道 gitlab cicd 怎么样。
mvn test 可以跳过，不跳过的话执行效率取决于你的单元测试代码，而不是 maven 。

4 、构建 Task 诊断问题
如果 maven 遇到打包错误，错误信息一般很明确
maven 应该是不支持一个多个 task 并发执行的，有这个需求，建议使用 gradle 。

[KongLiu]

gradle 兼容性感觉真的一坨

[diagnostics]

@mango88 你不能指责一个人做不到 X ，但是你来做，又不如这个人做的好。我只看到你说我不懂，我已经抛出了问题，也虚心的问，但你只说我不够深入，又不指明方向，你的回复有啥意义呢？纯粹口嗨吗？

对于多项目依赖，我们从 root -> 到 spring 多个 module 来分层维护 -> 回到 root + dependencyManagement ，我显然是做过调研的

对于依赖其他模块的测试的运行，你去看看 stack overflow 有答案吗，最新的答案还是我回答的，用的我的方案

那么问题来了，我不是遇到问题就吐槽，而不是有些问题，我没找到解决方案，官方几个插件甚至都没有多少文档。我不知道你从哪些地方去学习 maven ，如果是源码的话那真的没那个精力。。。

[doushini]

1. gradle 难学，语法不容易看不懂
2. gradle 慢，编译一个项目后台看几个 gradle 进程，还自动下载一堆 gradle.zip
3. maven 的 xml 格式清楚明白，而 gradle 乱七八糟的。

总之一句话，gradle 就是个垃圾

[abcbuzhiming]

maven 是包依赖管理工具，靠插件实现构建能力。
gradle 是构建工具，可以靠脚本实现各种匪夷所思的构建需求。

从以上你就能看出这两者的核心区别是什么，maven 就不是构建工具。

如果是简单的项目，比如现在大部分的后端 api ，也就几十个接口的那种，gradle 完全没必要，maven 的构建插件轻松搞定。

但是如果你的项目很复杂，比如 spring 这种已经是巨型的 framework ，再比如巨石型 APP ，你不用 gradle ，根本搞不定。


所以关键是你的开发究竟是哪个领域。就楼主来说，楼主是开发 framework 的，这一点和 spring 有点类似，而且楼主已经感觉到 maven 构建插件的上限了。这个时候，应该果断的换更强力的构建工具。


技术的应用，第一够用就好，第二如果不够用了要马上行动找解决方案。不要去评判好不好，技术的诞生都是有其自己的背景的，在这个背景下很好，换个背景就不适用了

[1835407125]

感觉 maven 挺好用啊，而且还是主流，出 bug 了也好解决。

[diagnostics]

@yusheng88

1. 我觉得只是大家先入为主，我看多了 sbt 的 build.sbt 我没觉得有多复杂，依赖管理更简单

2. maven 自己是能处理这些依赖的，idea 的 maven 插件不能处理，我开发想要启动的时候，启动不了（例如我有一个新的模块，本地代码有，但远程 nexus 在这个版本下是没有 artifact 的）

3. 你没懂我的意思，我想将测试分为 core, server, extension 独立跑，但是单独跑 exntension 会找不到 server 的依赖，必须先跑 server, 加个 am 能解决，但是除了编译 server ，还会执行 server 的测试，只能用 profile 解决

4. 不是打包错误，是我说的不够明显吗？ compile 的时候执行了一个 profile 下没有开启的 enforce 插件，理论上是不应该执行的，如果是 sbt 我可以通过 sbt-inspect 查看 compile 这个 task 依赖的上层 task 有哪些

[diagnostics]

@1835407125 三年前的问题，请你“好解决”帮大家解决一下： https://stackoverflow.com/questions/65004670/how-to-run-tests-only-for-a-single-maven-module

[fu82581983]

XML 如果是初学者可能会觉得繁琐，但是你如果用久了，你会发现它的结构与层次是最清晰的。

子模块管理问题，我倒没有遇到过，一般本地 install 之后，IDEA 就自动识别到最新的 SNAPSHOT 版本了。

CICD 问题，用 Jenkins 可以解决一部分，但是要特别灵活地编写 task ，估计只能上 Gradle 了。

[Suaxi]

公司新项目组的新项目全转到了 gradle ，我自己的小玩楞还是用的 maven

[yusheng88]

@diagnostics
1 、可能吧

2 、没太懂，依赖了没发版到 nexus 的模块？

3 、单元测试代码相互依赖吗？不太懂你的单元测试代码怎么写的。

4 、mvn 执行时，所有执行步骤都会顺序输出到控制台，有出于意料的操作，基本上都是有日志可跟踪的。我没见过 enforce 插件, 所以不评论， 但插件都可以自定义绑定执行阶段的

[Mystery0]

maven 有官方文档用来指导 pom.xml 怎么填写吗，里面的一些配置项又是怎样生效怎样配置的？
最简单的一个自动推送私服，翻来翻去都是各种教程博客让写什么什么，例如想把一个 fat-jar 的配置改成非 fat-jar 的，看到那个 pom 都没处下手不知道怎么改
所以我已经都用 gradle 至少官方文档会告诉我怎么去配置

[Mystery0]

至于说 gradle 下载很多版本的，执行 task 的时候用 gradle 命令而不是./gradlew 就和 maven 一样会使用系统装好的 gradle 了，这个时候版本全部都是由系统控制

[Aresxue]

1.xml 可读性主要是不够简洁，版本管理和子模块管理这俩本来就没有分开的必要，gav 一共就三个维度；
2.使用姿势有问题，把 revision 和 relativePath 玩明白就好了；
3.还是姿势问题；
4.了解下阿里的 amaven 还有开源的 maven daemon ；

[LPJD]

写 java 的，99.9%都是 maven 。上班复制粘贴了几年代码，没见过用 gradle 的，一次都没有见过

[Ayanokouji]

@Mystery0 #25 所以你读过 maven 文档吗
https://maven.apache.org/ref/3.9.8/maven-model/maven.html
https://maven.apache.org/ref/3.9.8/maven-settings/settings.html

[dupenn]

要用 gradle 替代 maven ，都喊了多少年了，以前也是各种博主推荐，为什么到现在还没把 maven 干下去？我觉得可能是 gradle 相对 maven 并没有很大的进步，否则老项目不愿意替换，新项目总应该会很多去尝试的吧，但是其实并没有很多新项目去尝试 gradle 。

[yazinnnn0]

我自己尽量不用 maven, 自己搞的玩具和公司自己一个人负责的项目全都是 gradle

[diagnostics]

@Aresxue

2. relativePath 目前都是 ../ 我试过多个层级，用 ../my-proj-parent 这样去依赖，也会有问题。

revision 我没用，revision 这个是 maven-version-plugin 做的，不支持插值替换和生成 efficiently pom ，所以我改成脚本替换 version 来发布了

3. 有啥姿势？例如 spring-aop 也依赖 spring-core 和 bean ， 单独跑 spring-aop 怎么做的不运行 core 的测试的？

[chendy]

我，因为 gradle 的高级特性用不到，maven 够用，不想折腾
另外手里好几个百万行的老项目还在直接用 javac 编译呢，也活得好好的…

[diagnostics]

@LPJD 可能写的都是 CRUD ，没接触过 Kafka 和 spring 这种项目吧

[diagnostics]

@chendy 唉，现在的也能用，其实最大的问题是，这个问题，你花一周时间迁移后，99% 覆盖了没问题了，舒服了，但是得到的提升感觉没太大意义，无非是对项目后续发展友好点。

我干着干着，突然觉得不如多看点其他书学习下，国内这种环境，没人在乎开发者体验

[chendy]

@diagnostics 其实说到开发体验这个事情，真的挺个人的
水平比较好的开发可能会倾向于使用更复杂的工具来更好的满足自己的个性化需求
但是现实中的情况往往是水平一般的开发居多，问题复杂一点就到处出问题，所以还是简简单单无功无过最好

[SoloCompany]

@diagnostics

> 3. 你没懂我的意思，我想将测试分为 core, server, extension 独立跑，但是单独跑 exntension 会找不到 server 的依赖，必须先跑 server, 加个 am 能解决，但是除了编译 server ，还会执行 server 的测试，只能用 profile 解决

mvn -am -pl :artifacts -D'test=package/name/*'

[diagnostics]

@SoloCompany 和 profile 差不多，am 不能只 compile ，maven 对依赖的定义太简单，只能依赖模块，不能单独依赖模块的测试、编译

[xubeiyou]

gitlab 的 cicd 好用么？感觉不够清晰- - 不如 jenkins 相对功能强大 组件多。Maven 的话确实在速度和一些多项目嵌套的时候会有一种杂乱无章的感觉 但是我觉得整体还是相对清晰明了的。。。

[SoloCompany]

至于 multi module project 的 sub-module 依赖找不到的问题, 根据经验 99.99% 是 version 没有写正确, 才会导致没有在 project tree 里 resolve 而是跑到 ~/m2 下载依赖了

正确配置的 multi module 没有遇到过 IDEA 无法识别的问题

[cccssss]

看了评论，发现楼主说的都对。maven 是垃圾

[hui9000]

maven 稳当啊。

[mango88]

@diagnostics #16

我们也是 root + dependencyManagement 的多模块项目

可以在底层模块的 pom 里增加以下属性

```
<properties>
<maven.test.skip>true</maven.test.skip>
</properties>
```
also make 会跳过此依赖模块的 test case

对底层模块进行跑单测时候，在命令行里覆盖掉此参数
```
mvn test -pl xxx -Dmaven.test.skip=false
```

[diagnostics]

@SoloCompany #40 IDEA 需要本地 install 一下就没问题，你觉得是版本没写对的问题？版本都是 1.0-SNAPSHOT 这种格式，只有发版后才会改为 1.1-SNAPSHOT ，maven 执行任何命令都没问题，只有 IDEA 报错。。。我尝试过 IDEA 用 maven 来编译，不好用。不如 sbt 这种能够后台运行的

[diagnostics]

@mango88 #43 和我们做法差不多，不过我为了方便，用 profile 把一类的模块分组到一块了，还是那个问题，maven 的支持不太细

[diagnostics]

@xubeiyou 不好用，必须用 docker 跑，天然比 jenkins 慢一个数量级，不然我也不会搞效率这个问题

除此之外，还有一个问题不支持多个 yml （虽然现在可以 include 了）无法区分 release 的 ci 和 merge request 的 ci

[guyeu]

写 Kotlin 、Scala 和 Java 甚至还带点 C++的混合项目，用了 gradle 已经回不去了

1. 多模块的支持比 maven 好，虽然 maven 有优化这方面的计划，但随意增减模块不用先`mvn install`就可以成功构建体验感会好一些；
2. 增量构建在日常开发中的加速效果明显，如果你不用 IDEA 这么高级的东东，随时修改随时编译随时允许 UT 的体验感 maven 是比不了 gradle 的，如果用了 IDEA 这种高级货，那么 IDEA 的编译和 maven 的编译是基本上是冲突的，IDEA 编译会破坏 maven 的编译，两边就都没办法“增量了”；
3. 项目越花哨，对构建脚本的功能性要求就越强，就势必要自己写一些扩展，这方面 gradle 很容易，简单处理的话直接在 build.gradle{.kts}里写函数就好，但是 maven 就复杂多了，基本上都得新建项目（另外，现在 gradle 支持 Kotlin ，有 Android 开发经验的同学几乎没有上手难度）；
4. 依赖的管理，用 maven 的话，有一种操作是在 pom.xml 里定义许许多多版本号的 properties ，然后在各种地方用，但是没办法跨项目用，gradle 有一个更优雅的搞法叫 versionCatalogs ，写一个 TOML 文件之后可以把它导入到各个项目；

然而 maven 这种完全声明式的构建机制是最简单，人类读起来也最没有心智负担的，如果项目的复杂度没有到一定程度，maven 就是最棒的（虽然 gradle 也在发明自己的声明式 DSL ）

[guyeu]

@diagnostics #46 gitlab 的 cicd 并不是必须用 docker 跑，gitlab-runner 支持很多种环境，而且允许用户自己注册自己的 runner 。docker 跑也不见得天然比 Jenkins 慢一个数量级。。。

release 的 ci 和 merge request 的 ci 可以用 rules 区分，rules 支持的规则就很多了，分支、事件源等等。。。这方面 Jenkins 使用的 webhook api 是很难和 gitlab 本身比的。

[diagnostics]

@guyeu #47 遇到大佬了

1. 最让我烦的就是增减模块的问题，3.6 比 3.5 多增加一个模块特性，就在哪里报错，但是日常开发有时候又需要去看 3.5 甚至 3.4 用户的 bug
2. 用了 sbt 的 增量就回不去了，IDEA 可以的构建可以用 maven 代替，但是实在兼容不好，不知道谁的问题
3. 暂不评价
4. 学习了

[diagnostics]

@guyeu #48 不用 docekr ，我理解不同 job 任务之间没法隔离吧？ ci 也都是从一个 image 开始，runner 的话，我记得我 4 年前看得文档是只能用 docekr 启动，宿主机直接安装 runner 好像当时觉得不干净没搞，后面都是公司 devops 在维护，只能说速度一言难尽，也可能是我们这边的问题，我们目前的 ci 没用到 gitlab 的 cache artifact

[monkeyk]

我们企业级应用，一直用 maven ，熟悉，可控

[nothingistrue]

感觉你不像是写 Java 的，Java 只能 Maven Gradle 二选一，一个 XML ，一个 Groovy ，都不能自洽，但没有第三个选择。

XML 比 Java 更通用，还是静态、对象语言，虽然是另一种语言，但比 Java 还更母语，只要 XML 能干，它永远都是作为 Java 的辅助配置的第一语言。于是 Maven 自然在大多数时候都能让 Gradle 靠边站——并不需要 gradle 有什么不好。

至于你的问题，一般人用不到，一般公司也遇不到。不过 Spring 是遇到了，它换了 Gradle 。

[guyeu]

@diagnostics #50 默认情况下一个 runner 同时只会执行一个任务，所以不会出现任务之间互相影响的情况。速度的话，Linux 上的 docker 和 Mac/Windows 上的 docker 不是一个物种，具体情况还是要具体分析。

[diagnostics]

@nothingistrue 我是写 Java ，所以才觉得这么久了，竟然只有 Java 和 Gradle 出来（更老的 ANT 就不说了）这两感觉都没有其他语言的构建工具好用

[diagnostics]

@nothingistrue 对了还有我提到的 Bazel： https://bazel.build/community/users?hl=zh-cn

[afeiche]

maven 比较适合固定的，变化不大的项目，一般配置好了，开发人员都不用去关注构建配置；你要是经常变，个性化需要比较多的，还是用 gradle 更灵活

[unco020511]

gradle 好用

[javaisthebest]

1. 你说 xml 可读性差 ？ json 可读性倒是比 xml 强一点 但是配置一多又不支持注释 你在复杂项目里面再找一个比 xml 的语言更好的出来？


2. 多去接触其他几种语言再说这种话吧 go 就没有包管理工具 依赖管理 go get 在 maven 面前简直就是烧火棍 c++也和原始人的武器差不多 js 的包管理 可以这么说前端那群人和黄狗撒尿一样到处标记 到处建轮子包管理工具


最后
年轻人爱追逐新东西是好事 但是有的时候多出去走走接触下

发现还是特么 maven 简单好用傻瓜式操作

[layxy]

我觉得 maven 还好吧,起码大家大版本一样只需要配置一次就可以了, gradle 下载开源项目,一个 gradle 版本下载一次,而且又大又慢,真不如 maven 方便,虽然配置方式比 maven 好点,公司 cicd 后端目前只支持 maven,不支持 gradle

[Leon777]

看场景选工具，一种新工具被开发出来并流行必然是为了解决某个实际问题，如果你的项目没有遇到此类问题那没有必要强行跟风

[marding]

目前觉得还行, 没觉得 maven 难用

[unclevv]

maven 十几年了，够稳定，够经典，还真有啥 maven 满足不了吗？那你得好好想想是不是没必要的需求了。

[awalkingman]

@alwaysonlinenet 我也想问

[qq135449773]

maven 更像是一种 build system ，golang/node/python 对应的 gomod 、pnpm 、pip 那种，除了 gomod 可能沾点构建的意思之外，其他那几个脚本语言，跟 maven 比更像是纯粹的依赖管理工具。。怎么能把这几样东西放在一起比呢。。

从 build system 的角度来看的话，maven 其实抽象能力也不行，灵活度远没有 Gradle 那种打开脚本就能写 task 那么方便，整个 flow 我个人感觉 mvn 控制起来也没有 gradle 那么精细。。。

这个问题归根结底还是得看项目复杂程度的，需要考虑当前项目能不能吃到 Gradle 的 benefit 了，吃不到的话用什么都一样。。。

[Nazz]

@javaisthebest 村里刚通网吗, 五六年前 go 就有官方包管理工具了

[sherlockwoo]

使用 maven helper 插件时怎么使用 clean install -am -pl 来自动构建依赖的包啊？

[OMGZui]

都在用，没啥区别

[blackmirror]

maven 管理还是非常好用的

[Daitabashi]

确实不直观， 确实各种依赖找不着，但也大概没有更好的了

[oamu]

@zhenjiachen gradle 可不慢。spring 因为 maven 构建太慢了，都切换到 gradle 去了。

[zhenjiachen]

@oamu 在我本地开发感觉是这样，maven 项目 reload 感觉比 gradle 快，第一次编译 maven 也是比较快，后面编译时间差不多。还有就是 idea 经常对 gradle 的索引失效 gradle 文件爆红需要重新索引，maven 没发生过。

[qingjiang]

android studio 使用 gradle 构建的，有时候没整明白，也只会配置相应环境

gradle 查阅资料比较少

maven 对 java 开发相对友好点

maven 参考资料比较多

[yb2313]

@Ayanokouji #1 pdm,启动

[ikas]

1.喜好问题,不做评价,个人喜欢 xml,讨厌一个人一个样的脚本
2.一个 parent 模块来做依赖 版本 插件管理. 其它模块继承自 parent,每个模块均是平级的.然后使用聚合项目来做模块管理,聚合你需要的模块,可以使用 profiles 来配置不同的聚合,也可以建立多个这样的聚合项目.聚合项目不继承 parent,与其他模块也是评级的
导入到 ide 时,只要选择聚合项目即可.如果需要 install 或者 idea 无法编译,那一定是 maven 模块配置问题
3.如果使用 2 的组合方式,那么只要精心配置好模块,利用 profiles 可以解决
4........

[duanzhanling]

maven 还是可以的，gradle 也不错

[xuanbg]

这不是 maven 的问题，而是架构设计的问题。子模块什么的，我们压根不许存在，都是直接打成二方包引用。所以跑单测也就值跑项目代码，不会连引用的都要跑一遍。

[diagnostics]

@ikas 你说了和没说一样，都是我们在做的，然而要用 profile 来实现，实际上很蛋疼。

一个功能：我在 scala 2.12 下，生成带 _2.12 后缀的版本，为了兼容，scala 2.13 就不带后缀。

有些通用包，没有 scala 依赖，那就需要手动关闭 mvn deploy, 不然 nexus 不能更新 release ，会让 ci 失败，所以光一个 scala profile 需要配置后缀，mvn deploy 开关

除此之外，对于一类单测，也需要 profile 跳过 maven surefire

维护多了你就知道不方便。


2 的问题是，有人提到过，删除模块的时候会遇到。

[Narcissu5]

maven 的多模块太蛋疼了，一个项目内的模块都不能直接相互依赖，必须通过版本，偏偏国内开发者又超喜欢拆模块
gradle 这方面好太多了，怕兼容麻烦有 wrapper

[diagnostics]

@Narcissu5 你说他简单，就一个 dependencies ，但是 sbt 的依赖管理也是这么干的，也能识别。
你说他就一个 dependencies ，代码不好实现，那又不学 gradle 搞个 project(xx) 来区别引入的是项目还是外部依赖

[magicZ]

懒得学加上我负责的模块没人动，一直用 maven

[me1onsoda]

cicd 这一点，我感觉分模块的 Java 都不太适合 cicd ，依赖的包一更新你发布的时候要对整个项目 install ？

[agostop]

Maven 的子模块确实有识别不出来的情况，但是最近的新版本的 idea 好像已经解决了吧？

[duanluan]

中央库新平台只支持 Maven 。https://central.sonatype.org/publish/publish-portal-gradle/

[tongqe]

好用不好用不是说出来的，而是用脚投出来的， [可读性] 这东西，大家接受才是真的好。另外这种依赖管理工具换个提效大的。软件工程领域需要解决的问题那么多，又不是重点不是改了能提升很多，为啥要改

[cruii]

op 那么牛，那 op 来改革中国互联网架构环境吧

[pangdundun996]

但是 IDEA 的识别不够好，总是出现某些子模块的版本找不到（ IDEA 无法识别到这些子模块就是我维护的，而不是第三方库，而是反过来，总是去远仓库下载而不是项目的 target 上查找）
------
这里有些没懂：
1 ）编译项目跟 IDEA 有啥关系，不还是依赖的 maven
2 ）你说找不到子模块，那 mvn clean compile 能过吗？

[blueswhisper]

如果 https://github.com/alibaba/jetcache 就是楼主现在参与开发的框架项目，感谢楼主丰富我黑名单库+1 。

[LichMscy]

我们之前尝试从 maven 迁移到 gradle 现在新的脚手架几乎全部用 gradle
最大的好处就是灵活（ gradle 是基于 java 开发），可以在 gradle 配置中用 java 编写很多自定义的东西，比如我们 pmd 、spotbug 这些都是基于 gradle 配置

[diagnostics]

@blueswhisper 这个倒不是，我只是举个例子，是不是我的话轻语让你破防了？

[hengyunabc]

看起来 LZ 是想要在不同的分支里随意切换，不同的分支里，可能有不同的 maven module 。

1. 切换失败，这个是 IDEA 的锅，这个和 maven 本身没啥关系。试想一个工程，不断的切换分支，不断的增加/删除 maven module ，这个是一个很复杂的问题，IDEA 也不可能做到完美。仔细想想里面各种加速的缓存，你要是 IDEA 的开发，可能也会觉得非常的头疼。
2. IDEA 就是有可能出现各种问题，所以不时可以重启一下。或者多数情况下，用命令行执行 `mvn compile` 。这样子能保证大部分情况下是正常的。
3. 可以用 mvnd : https://github.com/apache/maven-mvnd ，这个可以大大加速 maven 的编译
4. 如果是要不断切换分支，我建议是直接两个仓库，一个仓库一个分支，这样子不会有问题。还有一种办法是用 git worktree ，但这个用起来比较麻烦。
5. 在 maven 3.5.0 之后，直接支持了 ${revision} 的概念，不需要配置任何插件，直接全部 pom.xml ，只有一个地方控制版本号。https://maven.apache.org/maven-ci-friendly.html

[hengyunabc]

工程大了，单测多了必然会变慢，这个没啥办法。

可以考虑把单测并发执行，但这个对代码有一点要求。

还有一种办法是把集成测试和单测分开。单测用 surefire 插件，集成测试用 maven-failsafe-plugin 插件。

[iseki]

我这边的需要灵活的定制构建流程，中间还杂糅了其他语言的构建打包··· Maven 插件我不会写，Gradle 用着还算凑合，虽然也有许多不尽如人意的地方

[ajaxpost]

问题在于，不仅得你会，大家都得会，这才是重点

[iseki]

@duanluan 这是个大问题，此外新的仓库格式和协议是开放的吗，之前只看到了新的仓库，没想到这个他们也要改，这可改不得啊

[iseki]

@codingmiao 这个我倒是没有遇到过，Gradle 因为 API 经常不兼容，所以基本上都通过 wrapper 强行指定版本了······反而是 Maven 因为没这个问题，被人用上古版本炸过。

[diagnostics]

@hengyunabc #89 IDEA 主要会和构建工具自己的有点冲突，所以 scala 一般用 sbt 构建更好，IDEA 有这个选项，MAVEN 也有，但是 MAVEN 自己做不到增量编译，兼容性也不好，我开头里写了。

[diagnostics]

@hengyunabc #89 revision 就是通过 maven-version-plugin 做到的，实际用起来没法生成 efficiency pom

[matcloud]

Gradle 是真的好用，就像 Intellij Idea 一样，用了就再也回不到 Eclipse 了。

[HangoX]

gradle 搭配 gradlew 和 gradle wrapper 目前是 java 开发最好的实践，gradle 的灵活性太高了，用起来也很方便。默认的 groovy dsl ，可以让你直接用 java 写也可以，用 groovy 写也可以。如果时候 kotlin 起来的，可以直接用 kotlin dsl 搭配 gradle cache 还能做远程 cache 发送依赖。最后配合 gradle buildscan 可以界面分析构建慢的地方

[duanluan]

@iseki
Maven 中央库新平台我了解到的只有下列变更：
1. 如果要用原包名上传新依赖，需要发邮件申请迁移，迁移到新平台后无法撤回。
2. 需要换个插件，description 、scm.url 等必填，不再支持快照版本。
3. 发布新包无需发工单，发布后后台自行通过（或插件配置自动通过）即可。
4. 官方插件仅支持 Maven 。