有多少人还在用 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 ，写久了真的会降智（不思考合理性，不愿意接受其他，是的，我说的是我自己）

[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 有哪些