2

我们有一个多模块 POM，它也作为所有涉及的子模块的父 POM。调用它MultiModulePOM。我们有大约 70 个模块，例如编号Module1为Module70.

现在：这些模块中的前 30 个仅在编译时需要一组 JAR 文件。那就是 - scope=provided。由于我们讨论的是一组JAR 文件，因此让这 30 个模块保持同步非常乏味，而且总的来说，我不喜欢到处复制定义。

所以，我陷入了依赖分组的陷阱。似乎是个好主意，但它不适用于provided依赖项。换句话说：如果我将依赖的 JAR 分组到一个名为 的模块ExtDependencies中，并使Module1依赖于ExtDependencies，则引用的 JARExtDependencies不会被传递到Module1，因为它们的范围是provided.

（如果最后一段不是真的，请告诉我，因为它真的可以让我摆脱困境）

我能看到的唯一其他选项是创建一个名为 (for example) 的父 POM IntermediaryPOM。IntermediaryPOM扩展MultiModulePOM并使用scope=provided. 模块Module1-Module30然后扩展IntermediaryPOM.

这似乎可以解决问题，但我有三个问题：

  1. 它增加了另一层 POM，我不确定它是否真的需要。
  2. 后来，在分发期间，我发现自己也必须安装/部署中间 POM。
  3. 考虑一般情况：中间 POM 可能有其他兄弟用于其他 JAR 集（对于模块 31-50）。因此，这个解决方案似乎不能很好地扩展。

所以我的问题是 - 根据你的经验，解决这个问题的最佳方法是什么？这种用例的任何已知最佳实践？

4

1 回答 1

1

恐怕这里没有简单的解决方案。

您说得对，如果您在其中声明公共依赖项，ExtDependencies因为provided它们不会被添加到任何其他依赖于ExtDependencies. 就是这样provided工作的。

但是您可以在没有范围的情况下声明这些常见依赖项（例如，使用默认compile范围）并添加provided对ExtDependencies. 在这种情况下，所有ExtDependencies依赖项都将添加到类路径中。上帝，这是很多“依赖” :)

您还提到了其他可能的选择——引入另一个抽象级别（您可能知道，这是解决几乎所有问题的一种方法）。但是这种多层次的层次结构不太优雅，也更难维护（我在我们的项目中有它，所以我一直在那里）。

一般来说，我没有遇到过如此大规模的这个问题，但如果我要解决它，我会考虑到范围建议，选择第一个选项。

于 2013-02-07T18:08:31.870 回答