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

diagnostics

103 天前

@ikas #121

> 继承与组合是 maven 重要的特性,这里利用组合方式实现.本身就是其特性

哪里的见解？ maven composition 包下就一个依赖导入： https://maven.apache.org/ref/3.2.3/maven-model-builder/apidocs/org/apache/maven/model/composition/package-summary.html

搜索 composition in maven 第一个结果也是说 maven 用继承而不是组合的： https://melix.github.io/blog/2021/12/composition-in-gradle.html

官方文档也没有： https://maven.apache.org/guides/introduction/introduction-to-profiles.html

如果你的意思开启多个 profile 是组合的话，那当我没说。

另外 profile 也不是为了开关部分模块而设计的，更多的是环境、用例的不同。例如拿来写不同 JDK 下的编译，就没啥问题，开关 Spotless 好像也可以，但是维护多了有点繁杂

只开关部分模块的，依赖又会出问题，而且你单独开关部分的单测，维护起来一点也不友好.

在多项目里，你需要在每个项目里加这么一坨 shi：

<profiles>
<profile>
<id>xxxTest</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<skipTests>false</skipTests>
</configuration>
</plugin>
</plugins>
</build>
</profile>
</profiles>

一两个还好，十多个需要维护的模块呢？

为什么在你眼里非黑就是白呢？我觉得 Maven 不适合有复杂构建需求的项目，我说错了吗？你们觉得自己的项目复杂，不代表构建需求复杂。

Maven 能做到一些需求，不代表他做的好；我觉得在我的需求下，maven 做起来很别扭，没问题吧？

假如我能这么写：

```xml
<dependencies>
<dependency>
<groupId>com.example</groupId>
<artifactId>example-library</artifactId>
<scope>compile-only</scope> // 这里只会引入编译依赖关系，测试相关的任务不会尝试依赖关系
</dependency>
```

是不是方便许多，我还不需要用 Profiles 维护一大坨 shi 呢？为什么你们喜欢吃咸豆腐，要强迫我也认为咸豆腐是最好吃的？

我抛出我的问题，质疑 Maven 不思进取，大家的态度都是：我用的都好好的，你用不来是你的问题。

Diss 我的几个人，在我发代码之后，写了详细的步骤之后，有人 PR 解决了吗？好几天了，都没消息，这说明啥呢？

talk is cheap.....

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

1. xml 问题

2. 子模块管理问题

3. CICD 编写问题

4. 构建 Task 诊断问题

结论