我说的难用不是指难安装、简单打包，而是带一些场景：
1. xml 问题
xml 可读性某些层面太差了，过于繁琐，对版本管理，子模块管理全部揉杂在一起
2. 子模块管理问题
我们的项目组开发是一个 framework 的，也就是自身需要维护一大堆依赖，被别人引用的时候也会带上这些依赖的版本。
我们尝试过像 spring 那样用:
但是 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 ，写久了真的会降智（不思考合理性，不愿意接受其他，是的，我说的是我自己）
