如何修补 Maven 管理的框架中的子组件？
我需要为这个 bug 修补 mule-transport-jms 子组件 (http:// /www.mulesoft.org/jira/browse/MULE-3983）。 “修复”很简单，但让我烦恼的是，将修补后的组件部署到我的本地 Maven 存储库（由 Nexus 管理），并让它继续与 Mule 的所有其他组件良好地配合。
我想要的是将新修补的 mule-transport-jms 标记为版本号 2.2.1-patched，并让我的 esb 组件依赖于此，以及仍设置为版本的其他 mule 组件（例如 mule-core） 2.2.1.因为 mule-transport-jms pom 的内容（部分）是这样的：
<parent>
<groupId>org.mule.transports</groupId>
<artifactId>mule-transports</artifactId>
<version>2.2.1</version>
</parent>
<artifactId>mule-transport-jms</artifactId>
<packaging>bundle</packaging>
<name>JMS Transport</name>
<description>A Mule transport for Jms Connectivity.</description>
有许多相互依赖关系依赖于 2.2.1 版本。将父版本（如上所示）更改为 2.2.1-patched 会破坏所有内容，添加版本标记，使其看起来像这样：
<parent>
<groupId>org.mule.transports</groupId>
<artifactId>mule-transports</artifactId>
<version>2.2.1</version>
</parent>
<artifactId>mule-transport-jms</artifactId>
<version>2.2.1-patched</version>
<packaging>bundle</packaging>
<name>JMS Transport (ZFP patched)</name>
<description>A Mule transport for Jms Connectivity.</description>
破坏了可能在父 pom 中声明的许多依赖项（没有在任何地方提到那些失败的依赖项）在这个项目中）。
我也许可以破解 Nexus，以便在请求 mule-transport-jms v2.2.1 时始终检索我的修补版本，但这很脏。我真的希望能够在我的客户端 pom 中准确指定要使用哪个 GAV，并且当需要升级时（假设 bug 在 v3.0 中得到正确修复）只需更新我的客户端 pom 以指向版本3.0.0 和我打过补丁的 2.2.1 jar 只是被忽略，并且不需要对 nexus 进行黑客攻击。显然我也想避免检查每个 mule 组件并更新它们的 pom 并将它们全部重新部署为 2.2.1 补丁。
有什么想法吗？
I need to patch the mule-transport-jms subcomponent of mule for this bug (http://www.mulesoft.org/jira/browse/MULE-3983). The "fix" is straightforward but what is vexing me is deploying the patched component to my local maven repo (managed by Nexus) and having it continue to play nicely with all the other components of mule.
What I want is to label my newly patched mule-transport-jms as version number 2.2.1-patched, and have my esb components depend on that as well as the other mule components (eg mule-core) which are still set at version 2.2.1. Because the mule-transport-jms pom reads (in part) like this:
<parent>
<groupId>org.mule.transports</groupId>
<artifactId>mule-transports</artifactId>
<version>2.2.1</version>
</parent>
<artifactId>mule-transport-jms</artifactId>
<packaging>bundle</packaging>
<name>JMS Transport</name>
<description>A Mule transport for Jms Connectivity.</description>
there are many interdependencies that rely on the version being 2.2.1. Changing the parent version (as shown above) to 2.2.1-patched breaks everything, adding a version tag so that it looks like this:
<parent>
<groupId>org.mule.transports</groupId>
<artifactId>mule-transports</artifactId>
<version>2.2.1</version>
</parent>
<artifactId>mule-transport-jms</artifactId>
<version>2.2.1-patched</version>
<packaging>bundle</packaging>
<name>JMS Transport (ZFP patched)</name>
<description>A Mule transport for Jms Connectivity.</description>
breaks a number of dependencies that are presumably declared in the parent's pom (no mention of those failing dependencies anywhere in this project).
I can probably hack Nexus to always retrieve my patched version when mule-transport-jms v2.2.1 is requested, but that's dirty. I'd really like to be able to just specify exactly which GAV to use in my client pom, and when it's time to upgrade (assuming the bug gets properly fixed in v3.0, say) just update my client pom to point to version 3.0.0 and my patched, 2.2.1 jar just gets ignored, and no hacking of nexus is required. Obviously I'd also like to avoid checking out every mule component and updating their poms and redeploying them all as 2.2.1-patched.
Any thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您应该能够在 pom 中显式设置对
mule-transport-jms修补版本的依赖关系。因为它比标准版本更接近，所以它将覆盖标准版本并使用您的版本。您可能必须将依赖项添加到插件声明中。此博客文章 描述如何使用依赖项配置插件。如果这不起作用，您能否提供更多有关如何使用修补版本的信息？
You should be able to set the dependency on the patched version of
mule-transport-jmsin your pom explicitly. Because it is closer than the standard version it will override the standard version and yours will be used. You might have to add the dependency into a plugin declaration. This blog post describes how to configure a plugin with a dependency.If this doesn't work, could you provide a little more information on how you need to use the patched version?
应用补丁并重建整个
mule-transport作为版本2.2.1-patched可能是最好的解决方案。但我不知道这代表了多少努力（我的意思是构建时间）。另一种选择确实是构建 mule-transport-jms 模块的修补版本以及仅依赖于它的项目。为了轻松找到这些项目，您可以使用reactor来识别依赖的项目：
如果您使用的是maven 2.0.x
如果您使用的是 maven 2.1+
然后更新这些项目的 pom 以指向
mule-transport-jms的修补版本并重复 maven 命令来构建它们。我只是不知道这是否会比整个构建更耗时。
Applying your patch and rebuilding the whole
mule-transportas version2.2.1-patchedis probably the best solution. But I have no idea on how much effort (I mean build time) this represents.The other option would be indeed to build a patched version of the
mule-transport-jmsmodule and the projects that depends on it only. To easily find those projects, you could use the reactor to identify the dependent projects:if you are using maven 2.0.x
if you are using maven 2.1+
Then update the pom of those projects to point on the patched version of
mule-transport-jmsand repeat the maven command to build them.I just don't know if this will be less time-consuming than an entire build or not.
这实际上只是一个专家的问题，而不是 Mule 的问题。正确的方法不是使用“黑客”版本，而是在存储库中使用带有限定符的另一个版本（就像使用“修补”一样）。接下来，检查 maven 的传递依赖项（使用 mvn dependency:tree 和 dependency:list goal）并确保：
This is really just a maven question, not Mule's. The correct approach is not to have a 'hacked' version, but rather another version in the repo with a qualifier (just like you did with 'patched'). Next, inspect maven's transitive dependencies (use mvn dependency:tree & dependency:list goals) and ensure that: