使用 Maven 发布
我最近发布了一个maven项目，忍不住想整个过程非常复杂而且容易出错。假设我有一个由 3 个模块 A、B 和 C 组成的应用程序，每个模块在 subversion 中有自己的文件夹，在 Hudson 中有单独的构建作业。每个模块都有一个聚合多个工件的父 POM。 A 依赖于 B，B 依赖于 C。依赖版本在顶级 POM D 中定义，它是 A、B 和 C 的父级。它除了确保所有版本都保存在一个位置之外什么也不做。整个项目中使用的每个工件只有一个版本。为了进行发布，我执行以下操作：
- 通过 Hudson 使用发布插件发布顶级 POM D。
- 从 C 开始，没有进一步的依赖关系。
- 将 C 更改为引用 D 的已发布版本。使用发布插件发布 C。
- 在D中输入C的发布版本，这样依赖于C的模块就可以用C的稳定版本来发布
- 。使用发布插件再次发布D。
- 对 B 执行 3-5
- 对 A 执行 3-5
之后，我就拥有了 A、B 和 C 中所有工件的稳定非快照版本，并且可以将它们组装在一起形成应用程序的最终稳定版本。
事实上，我不仅有 3 个，而且有大约 20 个这样的模块。现在我发现这个过程非常复杂，我认为它有很多潜在的问题：
我需要多次释放 D，对于依赖层次结构中的每个级别一次。最后我得到了 D，其中只有 A、B 和 C 的稳定版本。要继续下一个开发版本，我必须再次编辑 D 并引用已发布模块的所有新快照版本。一般来说，依赖关系管理必须全部手动完成，即使使用发布插件也是如此。
如果有人在我发布时提交，可能会搞砸事情。可以肯定的是，我必须检查所有模块的特定修订版，构建并测试它，然后发布该修订版上的所有模块。但是我如何确保 Hudson 和多个作业能够做到这一点？
依赖于 3 个不同的系统：Subversion 服务器、Hudson 服务器和 Maven 存档服务器。如果只有一个宕机了，我就无法再发布了。
耗时。在这个过程中，我发布的每个模块都会一次又一次地进行大量的构建、打包、上传、下载、解压等工作。与存档进行大量冗余数据交换。但实际上一切都可以在本地完成，因为 Hudson 拥有它所需的所有源代码。最后只需上传一次最终包。
假设我在存档服务器上丢失了软件包。没有简单的方法可以告诉 Hudson 检查标记的版本并按正确的顺序重建它们。
为什么这不能像一次性签出所有代码、调整一个全局版本、构建和测试它、提交、标记提交并最终上传二进制文件那么简单？
感谢您对此的任何想法。
I recently released a maven project and could not stop thinking that the whole process is very complicated and error prone. Let us say I have an application which consists of 3 modules A, B and C, each having its own folder in subversion and a separate build job in Hudson. Each module has a parent POM which aggregates multiple artifacts. A depends on B, and B depends on C. The dependency versions are defined in a top level POM D, which is the parent of A, B and C. It does nothing else than making sure all versions are kept in one place and that there is only one version of each artifact used in the whole project. In order to make the release I do the following:
- Release the top level POM D with the release plugin through Hudson.
- Start at C which has no further dependencies.
- Change C to reference the released version of D. Release C with the release plugin.
- Enter the released version of C in D, so modules that depend on C can be released with the stable version of C.
- Release D again with the release plugin.
- Do 3-5 for B
- Do 3-5 for A
After that I have stable non-snapshot builds of all artifacts in A, B and C and can assemble them together to a final stable release of the application.
In real, I had not only 3 but like 20 such modules. Now I find this procedure very complicated and I think it has a lot of potential problems:
I need to release D several times, once for each level in the dependency hierarchy. In the end I have D with only stable versions of A, B and C in it. To go on with the next development version I have to edit D again and reference all the new snapshot versions of the released modules. In general, the dependency management has to be done all by hand, even when using the release plugin.
If somebody commits while I am doing the release it could mess up things. To be sure I would have to checkout a specific revision over all modules, build and test it, and then do the release for all modules on that revision. But how do I ensure that with Hudson and multiple jobs?
Dependent on 3 different systems: Subversion server, Hudson server and the Maven archive server. If only one is down I can not release anymore.
Time consuming. In this process a lot of building, packaging, uploading, downloading, extracting, etc. is made again and again for each module I release. A lot of redundant data exchange with the archive happens. But actually everything could be done locally, since Hudson has all the source code it needs. Just once in the end the final package needs to be uploaded.
Say I loose the packages on the archive server. There is no easy way to tell Hudson to check out the tagged versions and rebuild them all in the proper order.
Why can this not be as easy as checkout all the code in one shot, adapt one global version, build and test it, commit, tag the commit and finally upload the binaries?
Thanks for any ideas on this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
事情就是这么简单。使用父 pom，您可以让所有模块都指向同一个父模块。然后将子模块版本设置为：
${version.properties}，当您运行构建时，使用mvn -Dversion.properties xyx-SNAPSHOT（对于开发）运行它或xyz对于生产构建，那么所有模块都将使用相同的版本立即部署。因此，对于自动构建，要在 settings.xml 中指定
1.1.1-SNAPSHOT -Dx.yz覆盖 settings.xml 文件。唯一的技巧是你的父 pom 需要有一个非动态指定的版本，并且也需要在所有子文档中设置。因此，在每次发布之后，您可能需要手动更新该版本号（尽管可能有一个插件）
It can be that easy. Using a parent pom, you can have all your modules point to the same parent. Then set the child modules version to:
${version.properties}, when you run a build run it withmvn -Dversion.properties x.y.x-SNAPSHOT(for dev) orx.y.zfor a production build, then all the modules will be deployed at once with the same version.So for an automated build to to specify a
<version.properties>1.1.1-SNAPSHOT</version.properties>in the settings.xml, then if you need a released product specify an additional parameter at runtime with the-Dx.y.zto override the settings.xml file.The only trick to this is your parent pom needs to have a non-dynamically-specified version, and that will need to be set in all the child documents as well. So after each release you may want to update that version number manually (though there is probably a plugin for it)
如果您始终同步发布模块，我将为整个项目提供一个父 pom，其中包含所有模块并确保所有版本都相同。当你发布顶层时，它会按顺序发布所有模块，并一次性发布正确的版本。
If you are always releasing your modules in sync, I would have a single parent pom for the whole project which includes all the modules and makes sure all the version are the same. When you release the top level, it releases all the modules in order with the right versions in one go.