最佳方式* *提供的依赖

Question

我们有一个多模块POM，也作为对所涉及的所有子模块父POM。称它为MultiModulePOM。我们有大约70个模块，编号为Module1到Module70。

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

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

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

，我可以看到的唯一的其他选择是创建一个名为父POM（例如）IntermediaryPOM。 IntermediaryPOM扩展为MultiModulePOM，并将该组依赖JAR文件与scope=provided一起使用。模块Module1-Module30然后延伸IntermediaryPOM。

这似乎这样的伎俩，但我有三个问题是：

1. 它增加了POM的另一层那我不知道真正需要的。
2. 之后，在发布期间，我发现自己也必须安装/部署中介POM。
3. 考虑一般的情况下：所述中间POM可以具有用于其它套的JAR（对于模块31-50）其他兄弟姐妹。因此，这个解决方案看起来不太好。

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

Answer 1

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

你说得对，如果你在ExtDependencies中声明的公共依赖为provided，它们将不会被添加到任何其他依赖于ExtDependencies的模块的类路径中。这就是provided的工作原理。

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

你还提到了其他可能的选择 - 引入另一个抽象层次（你可能知道，这是一种解决几乎任何问题的方法）。但是，这种多层次的层次结构不够优雅，难以维护（我在我们的项目中使用它，所以我一直在那里）。

一般情况下，我还没有碰到过这样的问题，在这样的规模，但如果我要解决它，我会用第一个选项考虑到作用域建议去。