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

[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 。