我应该如何从多个来源共享 Maven DepdendencyManagement?

发布于 2024-12-07 05:47:19 字数 773 浏览 0 评论 0原文

我有一个 Maven 项目多模块项目。某些模块为其他模块生成的库创建自定义打包。正在使用的包装有其自己的版本化依赖项套件,我需要很好地使用它们。

举个例子:我的父 POM 可能有一个条目,例如 commons-codec:commons-codec 1.4,我的“core-lib”POM 将其作为依赖项包含(无显式版本),并且我想要确保我的打包模块捆绑在正确的版本中。但是,我使用的特定类型的自定义打包还需要例如 log4j:log4j 1.2.15,并且我想确保当我的打包模块运行时,它也捆绑了正确的 log4j 版本。

问题在于:我正在处理的“制作{自定义包装}的项目”的示例 POM 使用了自定义包装团队提供的父级。如果我使用它们的父级,我会丢失 commons-codec 的版本信息。如果我使用我的父级,我会丢失 log4j 的版本信息。

现在,通常如果我问“如何使 A 和 B 依赖于同一版本”,您会回答“使 A 和 B 具有相同的父版本,并在父版本中包含一个 dependencyManagement 部分” ”。我的问题是,我需要 A、B 和 C 依赖于相同的版本,但我对 C 没有任何控制权。

我认为这就是 Maven“mixins”要解决的问题,但当然它们还不存在。与此同时,我一直在做的是选择一个父项,然后从另一个 POM 中复制并粘贴 dependencyManagement 部分,并附上一条注释“确保保持最新” 。显然,这是一个丑陋的黑客,但我还没有找到另一种方法来与双方保持同步。

I have a Maven project multimodule project. Some of the modules create custom packaging for the libraries produced by the other modules. The packaging being used has its own suite of versioned dependencies that I need to play nice with.

As an example: my parent POM might have an entry for e.g. commons-codec:commons-codec 1.4, my "core-lib" POM includes it as a dependency (sans explicit version), and I want to make sure my packaging module bundles in the right version. However, the specific type of custom packaging that I'm using also needs e.g. log4j:log4j 1.2.15, and I want to make sure that when my packaging module runs, it also bundles the correct log4j version.

Here's the wrinkle: the example POM I'm working from for "project that makes {custom packaging}" uses a parent that's provided by the custom-packaging team. If I use their parent, I lose the version info for commons-codec. If I use my parent, I lose the version info for log4j.

Now, ordinarily if I ask "how do I make A and B depend on the same version", you'd answer "make A and B have the same parent, and include a dependencyManagementsection in the parent". My problem is, I need A, B, and C to depend on the same version, but I don't have any control over C.

I think this is what Maven "mixins" are meant to address, but of course they don't exist yet. In the meantime, what I've been doing is picking one parent, then copy-and-pasting the dependencyManagement section from the other POM, with a comment saying "make sure you keep this up to date". Obviously this is an ugly, ugly hack, but I haven't found another way to keep current with both sides.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

椒妓 2024-12-14 05:47:20

如何使用程序集插件来打包您的工件及其所有依赖项和让你的包装模块在其上运行?那么你就不会尝试任何 pom 魔法。这只是一个项目使用另一个项目的工件的问题,就像往常一样。

What about using the assembly plugin to pack up your artifact with all its dependencies and having your packaging module run on that instead? Then you're not trying any pom magic. It's just a matter of one project using the artifact from another project, like usual.

迷迭香的记忆 2024-12-14 05:47:20

现在,我将接受“这是 Maven 真正糟糕的事情之一”的答案。也许这个问题可以在 Maven 3.1 最终发布时得到更新。

For now, I'm going to accept the answer of "this is one of the really sucky things about Maven". Maybe this question can get updated when Maven 3.1 finally launches.

清音悠歌 2024-12-14 05:47:20

您是否无法激活多个配置文件,这些配置文件具有自己的依赖项部分,在启用时会拉取所需的库。由于可以激活配置文件的方式,这提供了一些很好的灵活性。

Could you not activate multiple profiles which have their own dependency section pulling in the required libraries when enabled. This allows some nice flexibility due to the ways that profiles can be activated.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文