你应该遮蔽你的依赖关系吗？答案

【问题标题】：Should you shade your dependencies?你应该遮蔽你的依赖关系吗？
【发布时间】：2018-01-12 11:33:48
【问题描述】：

对于我的工作，我每天都使用Spark。问题之一来自依赖冲突。我不禁想到，如果人们将他们的 jar 发布到他们自己的命名空间中，他们就会全部消失。

对于内部 jar，我正在考虑为所有依赖项执行此操作。除了一点点工作，我认为这是一个好主意。有没有我遗漏的缺点/风险？

【问题讨论】：

显然存在膨胀问题。如果包含 10 个库，每个库都有自己的 Spark 版本，那么 Spark jar 将是使用依赖解析选择单个版本的 10 倍。如果您将所有版本发布到存储库（例如 nexus），那么您可能会发现额外的 jar 开始在 nexus 上占用相当多的磁盘空间
这个问题是个坑，底部是一个认识——适合自己的就是最适合自己的。

【解决方案1】：

一些问题会随着着色而消失，但会出现新问题。一个问题是，您剥夺了用户使用与着色中使用的版本不同（已修补）版本的依赖项的机会。但着色的主要风险是着色类最终会暴露给客户。

因此假设您有 2 个依赖项 a、b，每个着色 log4j。因此，当您包含 a 和 b 时，您会在编译/运行时类路径中获得类 a.shaded.log4j.Logger(v1.3) 和 b.shaded.log4j.Logger(1.4)。你可能有自己的 log4j.Logger(1.5)。

然后您想在运行时对系统中的所有 Logger 执行某些操作，但突然您在运行时获得了许多不同的 logger 类和类版本。

因此，只有当您可以确保客户端不会通过您的库的 API 看到任何着色类的实例时，着色才是没有风险的。但这很难保证。也许使用 Java9 中的模块，这会少一些问题，但即便如此，在类路径上只有一个已知版本的任何类比大量使用相同名称但不同版本的阴影类更容易调试/管理。

【讨论】：