@flyqie 没人用了，出个免费版吸引注意力，觉得好用的就可能会买

任务调度？

@forgottencoast 你原来从 1x 缩放到 0.5x 的时候，会不会闪一下变成广角，会的话就有广角镜头。如果你现在缩放到 0.5x ，是闪成黑屏，那大概率是广角出问题了

广角镜头坏了吧

@ikas #121 另外你写的 module 方案，你觉的很优雅的解决了这个问题吗？


maven install -Pwith-1 ，多个项目下，我是不是每个项目都写一个 Profile ？精细度控制？

直接 maven install 先安装全部模块到本地仓库，十几个模块，编译速度还不如我直接 mvn test 的速度快呢，还只跑几个有依赖的模块编译

不过对于 cicd 来说，install 先安装，然后可以把本地 repo 当成共享的 cache ，可以一定程度避免代码的编译

@miracleyao 唉，迁移到 Gradle ，又要开始重新学 API （ Gradle 天天搞一些新特性），迁移成本对我们略高（我们现在大概 20 多个子模块。又恨 Maven 不成钢，不知道改进

@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.....

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

醒一醒，你比 AI 便宜

一直都是高度集成啊，另外难修不是价格良心。。。大量胶水才导致拆解慢，说白了就是为了美观和高度集成，不考虑维修，笔记本、ipad 这类没办法，整体价格高，容易坏，天天换新成本也受不了的。这类之所以做成这样就是因为坏的概率低，销售的量不多

@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 下优雅的解决方案