我们有一个相当大的 Java 应用程序，其中包含大量的 Maven 工件。每个子系统在 subversion 树中都有自己的文件夹，其中包含 trunk/、branches/ 和 tags/ 子文件夹，并托管多个工件。Maven POM 的层次结构有多个级别。甚至依赖管理也被分成不同的模块。该应用程序被部署为多个 WAR 和其他 Zip/JAR 内容。
在构建和部署它的过程中，我经常不得不将应用程序视为一个单元。我遇到了很多我想在这里分享的困难。
Subversion 布局：首先我不能只用一个命令检查整个代码库。当我从顶层开始检查所有子项目的所有分支时，它太大了，而且会花费太长时间。我想减少工件的数量目前并不是一个真正的选择，因为它会导致太多的根本变化。但可能是具有聚合分支文件夹的不同颠覆布局确实会有所帮助。我尝试的一种解决方法是创建一个包含大量颠覆外部的单独文件夹，将正确的子文件夹聚集在一起。然后，例如，我可以使用来自顶级多模块工件的一个 Maven 命令构建整个事物。
发布：发布是在整个代码库上完成的。首先，我制作了一个巨大的依赖关系图，其中我使用了专门为项目编写的自定义工具，因为无法直接使用 Maven 执行此操作。然后我必须在依赖关系树中逐步释放一层工件，从底部开始，从没有任何进一步依赖关系的工件开始，构建它们，如果成功地将父 POM 适应新版本，然后继续下一层. 有时我想把所有的版本控制工作做两次，一次是在 subversion 中，一次是在所有的 POM 中。发布插件似乎也不能自动适应依赖管理。
哈德逊：在 Hudson，我们为所有父工件提供了 20 个工作。每个工件都有 3 个活动分支。这创造了大约 60 个工作岗位。每次分支更改时，都会导致浏览器中的大量鼠标单击工作。至少依赖作业的自动构建触发正在工作。但是，如果一个模块被分成一个编译作业和一个报告作业，这又会导致问题。通常编译比生成报告要频繁得多，后者不应减慢前者的速度。但是，每当报告作业运行时，它也会触发所有编译作业。如果工件真的被部署，Hudson 似乎不能只触发依赖作业。我还尝试为整个项目制作一个巨大的多模块构建，但增量构建功能无法正常工作。没有它，构建需要的时间太长了。但是需要构建相关的工件，因为您永远无法确定一个工件会导致什么变化。
聚合报告：我还没有弄清楚如何为每个父 POM 级别的单元测试、测试覆盖率、检查样式和其他生成聚合报告。有些插件甚至不支持聚合选项。对于其他人，我必须为层次结构中的每个级别再次进行构建。Maven 站点报告还可以，但它们似乎是相当静态的，并且在浏览它们时用途有限。也许这里更好的选择是使用 Sonar Source 或其他一些源代码分析工具。此外，将这些报告整合到 Hudson 对我来说似乎并不理想。
从我的角度来看，我希望只有一个大存储库，在那里我可以签出一个目录，从源代码构建所有内容，为发布制作一个标签/版本，不依赖任何外部存储库并在 Hudson 中配置一项工作。但这可能与不同开发团队的需要相去甚远。似乎很难为两者找到一种易于管理的方式。