Question

我正在思考一个想法，并想为开发者社区提出一个问题。当我在实践中使用maven进行大规模JAVA项目时，会产生惊人的好处。然而，项目正在快速增长，随着时间的推移，更多模块会出现，从而导致庞大的构建时间以及不会对持续集成产生影响。

问题 - 是否有一些开箱即用的功能允许智能项目构建，首先可以检查模块目标jar是否与位于本地maven存储库中的模块不同。如果后者是真的，maven可以继续使用下一个模块而无需重建和重新部署相同的模块吗？

此致

Answer 1

最好的方法是切换到Maven 3，它通过

支持并行构建

mvn -T 3.0C clean package

还可以帮助建立可以通过Maven实现的改变：

mvn -pl module -am package

还有许多CI系统，如jenkins支持增量构建。还要检查哪种测试正在运行？你可以并行运行单元测试吗？（行家-万无一失-插件）。这些单元测试真的是单元测试还是其中一些集成测试？

Answer 2

这个问题没有灵丹妙药。它是许多大型项目所面临的普遍问题。

CI被触发的事实通常是由SCM提交，所以我建议事情总是发生变化。

在不知道您正在使用什么CI，如何配置模块等的情况下，除了一些基础知识之外，我无法提供更多建议。

1）确保您在CI中配置的模块尽可能精细 - 即尽可能小的构建单元。这意味着单个提交不需要重建代码。

2）开发人员习惯：只提交一个完整的工作单元。这就是Git的意思。开发人员在本地提交，然后仅在工作单元完成时才推送到主服务器。这减少了下游CI构建。

3）观察您在Maven中使用的报告和模块。有些人需要永远奔跑。你真的需要它们吗？

Answer 3

问题 - 是否有一些开箱即用的功能允许智能项目构建，首先可以检查模块目标jar是否与位于本地maven存储库中的模块不同？ [...]

我所知道的唯一“智能”是跳过你不需要的构建中的“干净”阶段 - 这样一些源将不会被编译，或资源被不必要地重新生成。仍然，项目将被重新包装。

您可能还考虑将某些模块排除在不同的开发周期中（除非您确实需要在每个版本中对所有模块进行更改）。然后，经常更改的模块可以作为存储库中的依赖项包含在内 - 它们需要单独构建和部署。

Answer 4

（假设：团队内部存储库。）

离线（如果被插件尊重）构建：

mvn -o ...

（假设：IDE构建绕过maven（在后台进行增量编译）。

跨模块依赖关系的限制。 从其他模块导入非常容易，有时会出现纠结的依赖关系。