在 Subversion/Maven/Hudson 中管理大型多模块项目
我们有一个相当大的 Java 应用程序，其中包含大量 Maven 工件。每个子系统在 subversion 树中都有自己的文件夹，其中包含 trunk/、branches/ 和 Tags/ 子文件夹，并托管多个工件。 Maven POM 的层次结构有多个级别。甚至依赖管理也被分成不同的模块。该应用程序被部署为多个 WAR 和其他 Zip/JAR 内容。
在构建和部署它的过程中，我经常必须将应用程序视为一个单元。我遇到了很多困难，我想在这里分享。
Subversion Layout：首先，我不能仅使用一个命令来检查整个代码库。它太大了，当我从顶层开始并检查所有子项目的所有分支时，它会花费太长时间。我想减少工件的数量目前并不是一个真正的选择，因为它会导致太多的根本性变化。但可能具有聚合分支文件夹的不同颠覆布局确实会有所帮助。我尝试的一种解决方法是创建一个包含大量 subversion 外部文件的单独文件夹，将正确的子文件夹聚集在一起。然后，我可以使用顶级多模块工件中的一个 Maven 命令构建整个内容。
发布：发布是在整个代码库上完成的。首先，我制作了一个巨大的依赖关系图，其中我使用专门为该项目编写的自定义工具，因为无法直接使用 Maven 来执行此操作。然后，我必须逐步释放依赖关系树中的一层工件，从底部没有任何进一步依赖关系的工件开始，构建它们，如果成功地使父 POM 适应新版本，然后继续到下一层。有时我想将所有版本控制工作做两次，一次在 subversion 中，再一次在所有 POM 中。发布插件似乎无法自动适应依赖管理。
Hudson：在 Hudson，我们为所有父工件提供了大约 20 个作业。每个工件都有 3 个活动分支。这相当于创造了 60 个工作岗位。每次分支更改时，都会导致浏览器中进行大量鼠标点击工作。至少依赖作业的自动构建触发正在工作。但如果一个模块被分成编译作业和报告作业，这又会导致问题。通常编译的频率比生成报告的频率高得多，并且后者不应减慢前者的速度。但每当报告作业运行时，它也会触发所有编译作业。如果真正部署了工件，Hudson 似乎无法仅触发相关作业。我还尝试为整个项目创建一个巨大的多模块构建，但增量构建功能无法正常工作。如果没有它，构建就会花费太长时间。但是构建依赖工件是必需的，因为您永远无法确定一个工件会导致什么变化。
聚合报告：我还没有弄清楚如何为每个级别的父 POM 的单元测试、测试覆盖率、检查样式等生成聚合报告。有些插件甚至不支持聚合选项。对于其他人，我必须为层次结构中的每个级别再次进行构建。 Maven 站点报告还可以，但它们似乎相当静态，并且在浏览时用途有限。也许这里更好的选择是使用 Sonar Source 或其他源代码分析工具。此外，将这些报告集成到 Hudson 对我来说似乎并不理想。
从我的角度来看，我希望只有一个大存储库，我可以在其中签出一个目录，从源代码构建所有内容，为发布创建一个标签/版本，不依赖于任何外部存储库并在 Hudson 中配置一项作业。但这可能与不同开发团队的需求相去甚远。只是不知怎的，似乎很难找到一种对两者都可管理的方式。
We have a rather big java application which consists of tons of maven artifacts. Each subsystem has its own folder in the subversion tree with trunk/, branches/ and tags/ subfolders and hosts multiple artifacts. The hierarchy of Maven POMs has multiple levels. Even dependency managemnt is split up into different modules. The application is deployed as multiple WARs and other Zip/JAR stuff.
In the process of building and deploying it, I often have to view the application as one unit. And I came across a bunch of difficulties I wanted to share here.
Subversion Layout: It starts with the fact that I can not just checkout the whole code base with one command. It is simply too big and would take too long when I start at the top level and checkout all the branches from all subprojects. I guess reducing the number of artifacts is currently not really an option since it would cause too much fundamental changes. But may be a different subversion layout with aggregated branches folders would indeed help. One workaround I tried is to make a separate folder with lots of subversion externals, that gather together the right subfolders. I can then for example build the whole thing with one maven command from a top-level multi-module artifact.
Releasing: A release is done over the whole code base. First I make a huge dependency graph, where I use a custom tool written specifically for the project, since it is not possible to do this with Maven directly. Then I have to incrementally release one layer of artifacts in the dependency tree, starting at the bottom with artifacts that do not have any further dependencies, build them, if successful adapt the parent POMs with the new versions, and move on to the next layer. Sometimes I feel like doing all the versioning work twice, once in subversion and once again in all the POMs. The release plugin does not seem to be able to also adapt dependency management automatically.
Hudson: In Hudson we have like 20 jobs for all the parent artifacts. And for each artifact there are 3 active branches. This makes like 60 jobs. Everytime a branch changes it causes a lot of mouse clicking work in the browser. At least the automatic build triggering of dependent jobs is working. But then again this causes problems if a module is split up into a compile job and a report job. Usually compiling is done a lot more frequent that generating reports, and the latter should not slow down the former. But then whenever the report job runs, it also triggers all the compile jobs. Hudson does not seem to be able to only trigger dependent jobs if the artifact is really deployed. I also tried to make one huge multi-module build for the whole project, but the incremental build feature does not work correctly. And without it builds are taking just too long. But building dependent artifacts is required, since you can never be sure what a change it one artifact causes.
Aggregate Reports: I did not yet figure out how to generate aggregate reports for unit tests, test coverage, checkstyle and others for each level of parent POMs. Some plugins even do not support a aggregate option. For others I have to do the build again for each level in the hierarchy. Maven site reports are okay, but they seem to be fairly static and only of limited use when browsing them. Maybe the better option here would be to use something like Sonar Source or some other source code analysis tool. Also the integration of these reports into Hudson seems not ideal to me.
From my perspective I would like to have just one big repository, where I can checkout one directory, build everything from source, make one tag/version for a release, have no dependencies on any external repositories and configure one job in Hudson. But this is maybe far away from what the different developer teams need. It just somehow seems to be difficult to find a manageable way for both.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不知道这是否是一个简单的答案，但我有一个类似的项目（代码方面）：2 个大型应用程序，一个包含大约 10 个模块，另一个包含 15 个模块。我们拥有一个颠覆存储库中的所有内容（例如 svn/trunk/app1 和 svn/trunk/app02）。在根文件夹（svn/trunk）中，我们有一个非常简单的 pom，它将版本和两个应用程序定义为子模块。
通过此设置，我们可以完成您提到的大部分操作。甚至与每个开发团队分离，因为每个团队致力于不同的文件夹/项目。我们甚至存储其他工件，例如文档和设计（svn/trunk/documentation），因此我们可以跟踪特定版本的文档。
我知道这并不能回答您的第一个问题（您无法签出所有代码库），但是为什么您需要“签出所有子项目的所有分支”？这听起来不对。你有快速连接到 svn 服务器吗？
注意：我们不会生成合并报告，因为我们更感兴趣的是每个应用程序都有一个报告，因为它们非常不同。
I don't know if this is a simplistic answer, but I have a similar project (codewise): 2 big applications, one with about 10 modules and one with 15 modules. We have is everything in one subversion repository (e.g. svn/trunk/app1 and svn/trunk/app02). In the root folder (svn/trunk) we have a very simple pom that define the version and both applications as submodules.
With this set up we can do most of what you mentioned. Even the separation from each development team, as each team commits to a different folder / project. We even store other artifacts, such as documentation and design (svn/trunk/documentation), so we can track what documentation we had for a specific version.
I know that this doesn't answer your first concern (you cannot checkout all the code base), but why do you need to "checkout all the branches from all subprojects"? That doesn't sound right. Do you have a fast connection to the svn server?
Note: We don't generate combined reports, as we're more interested in having a report per application, as they're quite different.