你如何解决Maven / Gradle中几个级别间接缺失的依赖地狱？

Question

我们有一个依赖于Aspose Words＆＃39; com.aspose:aspose-words:16.10.0:jdk16。

aspose-words的POM声明没有依赖关系，但事实证明这是谎言。它实际上使用jai-core，其最新版本位于javax.media:jai-core:1.1.3。

jai-core的POM也是谎言 - 它声明没有依赖关系，但实际上取决于jai-codec，com.sun.media:jai-codec:1.1.3。

让这些项目解决问题似乎不切实际。 JAI基本上是一个死的项目，Maven Central不知道谁添加了POM，所以没有人负责修复元数据。 Aspose拒绝在没有测试的情况下修复它，即使你可以向他们展示自己错误的代码，即使他们修复了它们，他们也会依赖jai-core:1.1.3添加它们，这只能解决问题的一半。反正。

如果我查看整个依赖树，这只是问题的一个例子。其他人潜伏着，被其他依赖链掩盖，巧合地拉入了缺失的依赖。在某些情况下，我们甚至向项目报告了POM问题，只是为了让他们说依赖性并不是真实的，尽管他们的课程明确指的是另一个库中的一个类。

我可以想到一些同样尴尬的选择：

• 创建jai-core:1.1.3.1和aspose-words:16.10.0.1并修复其POM以包含缺少的依赖项，但是将来更新它们的任何人都必须执行相同的操作。此外，任何其他库我不知道哪些依赖于jai-core也必须更新。
• 从我们自己的项目添加依赖项，即使它实际上不是一个。
• 编辑现在用于直接修复问题的版本的POM，只是警告人们可能已经缓存了错误的版本。

所以我想我有两个相关的问题：

• 有没有正确的方法来解决这个问题？似乎任何非玩具项目最终都会遇到这个问题，所以没有明显正确的处理方式令人担忧。
• 有没有办法阻止不正确的依赖元数据首先进入工件服务器？它已经失控了，因为团队中的其他开发人员正在添加依赖项而没有正确地检查事物，然后我会在一年之后发生故障时离开以清除错误。

Answer 1

Tunaki已经提供了许多好方法。让我添加以下内容：

我们不得不处理许多遗留罐子，这些罐子是MavenCentral上现有罐子的旧版本或奇怪版本。我们给了他们一个特殊的版本号（比如1.2.3-companyname）并为他们创建了符合我们目的的POM。这或多或少是你的第一个“尴尬选择”。这就是我在你的情况下会采取的措施;另外，我会在dependencyManagement中定义版本，以便Maven依赖中介不会将其设置为其他版本。

如果你的jar的新版本出现，你可以检查它是否仍然有相同的问题（如果他们做了正确的Maven构建，他们应该在POM内部拥有所有依赖项）。如果是这样，您需要再次修复它。

我不会更改现有版本的poms，因为它会让人感到困惑并可能导致不一致问题，因为如果旧版本已经在本地存储库中，Maven将不会获取新的POM。如果您只有很少的项目需要管理，那么将依赖项添加到您自己的项目是一个选项，这样您仍然可以看到正在发生的事情（对POM中的依赖项的正确评论可以使其更清晰）。

Answer 2

JAI对于Aspose.Words for Java是可选的。 Aspose.Words for Java仅在可用时才使用JAI图像编码器和解码器。如果没有JAI，它会正常工作。

编解码器补充了标准的Java ImageIO编码器/解码器。最显着的补充是对Tiff的支持。

JAI（Java Advanced Imaging）不是常用的库。首先 - 它是本机库。即它为不同的平台提供单独的分配。它还具有“便携式”纯java分发，但如果你想要JAI的全部功能 - 你应该坚持原生选项。

另一件事：通常你应该在主机系统上运行JAI原生分发的安装。即它像桌面应用程序一样安装，而不像通常的java库。同样，JAI编解码器的行为与通常的库不同：如果它安装在系统上 - 它将插入到与路径无关的ImageIO中。

所以，我不知道使用Maven安装JAI的好方法 - 就像使用Maven安装Skype或任何其他桌面应用程序一样。但这是恕我直言，我不是Maven的专家:)