P 站 、Facebook 是 PHP ，Github 是 Ruby ，前期是怎么快怎么来，后期体量大了都得重构

醒一醒，你比 AI 便宜

@ikas 1. maven4 解决了依赖问题吗？不过我还没听过 maven4 ， 我印象最新的版本还是 3.9 ，刚才去看了下好像还是 alpha 版本

2. 你说的那个在我的 PR 了提了，我的问题其实不是怎么解决，你这个方案，本质上还是 maven 没有特性，导致用户需要投机取巧的方法来实现

618 以旧换新的补贴吧，好像是政府的

@safarigu #5 第二个看着怎么这么怪，“全国可飞”

推特看别人吐槽过，1TB 的 mac 里面 200 多 g 是它，穷人干不了 rust 开发

@iseki #114 不知道你用的是不是 maven 、假如不搞 profiles ，那么多项目多插件，绝对让你的编译速度直线下降：

你可以看我帖子里的 github 仓库的分析有解释，maven 没有定义具体能依赖什么阶段，你执行 package 就会把之前的所有阶段一起跑了，包括你依赖的模块

多项目，多插件之后，执行速度是 ：模块数量 * 插件数量

对于大型项目，spotless, findbugs, enforce, sortpom 等校验插件是平常的事, 如果内部还有其他定制化和功能插件，那速度更别说了

@31415926535x #112

1. 我没看懂你提的用更好的工具链来加速这个事情，目前我们是 gitlab ci/cd ，即使我做了 cache 了提前 compile 的产物，再 test ，也没法增量编译，你可以去深入 maven 增量编译这个事情。

2. 项目结构合理性：这个我们考虑过，可以用接口把一些依赖耦合给解耦，例如 aop -> bean 的依赖，bean 可以搞个接口模块，这样即使 aop 测试需要一来 bean-interface, 但是也不会跑任何实现的逻辑，bean 可以单独跑。但问题是：不是所有模块都支持这样、以及工程会有点复杂。换句大白话说，这是你构建工具可以解决的事情。

3. 你说的先构建并行吧啦巴拉，这些，我大概理解你的意思。和 1 差不多，maven 不支持增量编译，所以应该需要先打包 deploy 到 nexus ，才能被其他模块拉到并更新。我们要做的事情就是 ci/cd 里面搞并行化。aop 、bean 本质上是同级模块，只不过有依赖关系，强行搞成两个 stage ，会遇到我说的，先 deploy 才行。

4. 是 feature 不是 future ，我感觉你工作经验不久？或者接触的项目比较单一（都是公司里面做单个微服务项目），你随便找个开源项目就知道开源 git 的工作流和公司里面的业务项目不太一样，简单来说分为两个：

- Trunk Based Development：基于 dev 、sit 、prd 这种分支开发，每个人提交到 dev ，提交合并需要 review
- Github flow/ Gitlab flow：拉出一个分支开发，再合并到 main 分支，根据发版还有不同的 release

这是 Git 用法的两个模式，和本文完全没关系，我没太理解你认为适合的 workflow 是那一种，目前我们是 gitlab flow

@blueswhisper https://github.com/d789a08a-66a8298fd305/maven-issue

“Talk is cheap. Show me the code.” 问题直接贴到 Github 了，欢迎您提 PR 给出一个 Maven 下优雅的解决方案

@yusheng88 你说的没错，我确实是来骂 maven 的，因为我遇到的问题，基本上都在 maven 不好解决，设计问题，我觉得 maven 太老了，吐槽一下。就算能解决我说的问题，也是很复杂的解决，这算一个好框架？

基础框架组遇到过，但是没遇到过这问题，emmmmm

其实我说的问题，不搞 cicd 并行化，也比较难遇到，只能说人和人的追求不一样，有些人写代码只是能跑就行，和基础框架组没什么关系。有些人会去思考，怎么跑得更好，怎么设计的更好。

我的同事，非组内的，学习积极吗？积极，各种书籍天天看，实际在工作里，代码能写多捞就写多捞。

@yusheng88 “Talk is cheap. Show me the code.”

https://github.com/d789a08a-66a8298fd305/maven-issue

@31415926535x 你能这么问，说明你没维护过结构复杂点的项目呗

以 spring 来说，
- aop 依赖 core 、bean
- bean 依赖 core
- context 依赖 aop 、bean 、core

你想单独跑 aop 的单测是不行的，一定会先去编译相应的依赖（ core 、bean ）两个方案：

1. 在单测前编译一轮，缓存起来
2. 用 maven 参数 --also-make 编译依赖

如果你用 2 ，不在 ci 搞文章，或者你本地想测试了，直接 mvn clean test -pl aop -am 的话，会把 core 、bean 的单测一起执行了，这是因为 maven 对依赖只有一个 artifact id 声明，没有其他依赖关系，以在 V2EX 被人吐槽的 sbt 为例，依赖可以是

.dependsOn(bean % "compile->compile;test->test", core)


上面的含义是，依赖 bean 的代码和测试，依赖 core 的代码。

maven 能做到吗？也可以：mvn clean compile -pl aop -am & mvn test -pl aop

我一直吐槽的是，maven 做起来复杂，而不是 maven 无法实现，但是楼里有些人冷嘲热讽，说白了这些人不愿意接受新鲜东西，老古董，我发现文化人大多都有这个问题，学多了就认为自己的体系是对的。

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

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

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

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