我在思考一个想法，并想向开发人员社区提出一个问题。 由于我在大规模的JAVA项目中使用maven在实践中具有惊人的益处。然而，随着时间的推移，项目正在迅速增长并出现更多模块，从而导致构建时间巨大，并且这对持续集成没有影响。Maven 2.2.1优化项目构建时间
的问题 - 有一些现成的功能，将允许智能建筑项目，可以先检查是否有模块目标罐子从一个位于本地Maven仓库不同。如果后者是真的，maven可以继续到下一个模块，而不需要重建和重新部署相同的模块？
Regards
最好的办法是切换到Maven 3支持并行通过建立
mvn -T 3.0C clean package
什么也帮助是建立什么变化，可通过Maven的实现：
mvn -pl module -am package
也做许多像詹金斯这样的CI系统支持增量构建。还要检查哪种测试正在运行？你能并行运行单元测试吗？ （行家-万无一失-插件）。这些单元测试真的是单元测试还是可能其中一些集成测试呢？
这个问题没有灵丹妙药。这是许多大型项目面临的普遍问题。
CI触发的事实通常是由SCM提交，所以我建议总是改变一些东西。
不知道你在用什么CI，模块是如何配置的等等。除了一些基础知识之外，我不能提供很多建议。
1）确保您在CI中配置的模块尽可能细化 - 即尽可能小的构建单元。这意味着单个提交不需要重新编译大量代码。
2）开发者习惯：只提交一个完整的工作单元。这就是Git所关心的。开发人员在本地进行提交，然后只在工作单元完成时推送给主设备。这减少了下游CI构建。
3）查看您在Maven中使用的报告和模块。有些需要永远运行。你真的需要他们吗？
问题 - 是否有一些开箱即用的功能，可以让智能项目建设可以首先检查模块目标jar是否与位于本地maven repository中的模块不同？ [...]
唯一的“机灵”我知道是跳过“干净”阶段构建，你不需要—这样一些消息来源不会被编译，或者不必要的资源再生。不过，项目将被重新包装。
你也可以考虑一些模块排除到不同的开发周期（除非你真的需要在每一个版本在所有这些变化）。然后，更新频率较低的模块可以作为依赖关系从资源库—中提取出来，这些模块需要单独构建和部署。
（假设：团队内部repositiory）
脱机（如果授予由插件）构建：
mvn -o ...
（假设：IDE建立在后台绕过行家（增量编译）
限制交叉模块的依赖关系从其他模块导入非常容易，有时候会出现纠结的依赖关系网
这些都是您提出的伟大的观点/建议，并且每一项都经过了审查和实施，然而想法还是要走得更远。感谢您的想法和建议。 – Xeperis