分组*提供*依赖关系的最佳方式

Question

我们有一个多模块POM，它也可以作为所涉及的所有子模块的父POM。称之为MultiModulePOM。我们有大约70个模块，比如Module1到Module70。

现在：这些模块中的前30个在编译时只需要一组JAR文件 。那是 - scope=provided。由于我们讨论的是JAR文件的 set ，将这30个模块保持同步是非常繁琐的，而且一般来说，我并不是复制定义的忠实粉丝。

所以，我陷入了dependency grouping的陷阱。看起来像一个好主意，但它不适用于provided依赖项。换句话说：如果我将依赖JAR分组到名为ExtDependencies的模块中，并使Module1依赖于ExtDependencies，则ExtDependencies引用的JAR将不会传递性地添加到Module1，因为它们的范围是provided。

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

我能看到的唯一其他选项是创建一个名为（例如）IntermediaryPOM的父POM。 IntermediaryPOM扩展MultiModulePOM并使用scope=provided登记依赖JAR文件集。模块Module1 - Module30然后扩展IntermediaryPOM。

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

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

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

Answer 1

我担心这里没有简单的解决方案。

您说得对，如果您将ExtDependencies中的公共依赖项声明为provided，则不会将其添加到依赖于ExtDependencies的任何其他模块的类路径中。这就是provided的工作方式。

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

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

总的来说，我没有在这样的规模上遇到过这个问题，但如果我要解决这个问题，我会考虑第一个选项并考虑范围建议。