7

这里是 Java 8。

假设有一个旧版本的widget库，带有 Maven 坐标widgetmakers:widget:1.0.4，其中定义了一个类，如下所示：

public class Widget {
    private String meow;

    // constructor, getters, setters, etc.
}

岁月流逝。这个widget库的维护者决定 aWidget永远不应该meow，而是事实上应该bark。于是有了一个新版本，它带有 Maven 坐标widgetmakers:widget:2.0.0，Widget看起来像：

public class Widget {
    private Bark bark;

    // constructor, getters, setters, etc.
}

所以现在我去构建我的应用程序，myapp. 而且，想要使用我所有依赖项的最新稳定版本，我这样声明我的依赖项（在内部build.gradle）：

dependencies {
    compile (
        ,'org.slf4j:slf4j-api:1.7.20'
        ,'org.slf4j:slf4j-simple:1.7.20'
        ,'bupo:fizzbuzz:3.7.14'
        ,'commons-cli:commons-cli:1.2'
        ,'widgetmakers:widget:2.0.0'
    )
}

现在假设这个（虚构的）fizzbuzz库一直依赖于 1.x 版本的widget库，Widget而meow.

所以现在，我widget在我的编译类路径中指定了 2 个版本：

  1. widgetmakers:widget:1.0.4它是由库拉入的fizzbuzz，作为它的依赖项；和
  2. widgetmakers:widget:2.0.0我直接引用

很明显，根据Widget首先加载类加载的版本，我们将拥有 aWidget#meow或 a Widget#bark。

Gradle 是否提供任何设施来帮助我？有没有办法拉入同一个类的多个版本，并配置fizzbuzz类使用旧版本Widget，而我的类使用新版本？如果没有，我能想到的唯一解决方案是：

  1. 我可能能够完成某种基于着色和/或 fatjar 的解决方案，也许我将所有依赖项作为包拉入其中myapp/bin，然后为它们提供不同的版本前缀。诚然，我在这里没有看到明确的解决方案，但我确信有些事情是可行的（但完全是 hacky/讨厌）。或者...
  2. 仔细检查我的整个依赖关系图，并确保我所有的传递依赖关系不会相互冲突。在这种情况下，对我来说，这意味着要么向维护人员提交拉取请求以将fizzbuzz其升级到最新widget版本，要么不幸的是，降级myapp以使用旧widget版本。

但 Gradle （到目前为止）对我来说很神奇。所以我问：这里有什么 Gradle 魔法可以帮助我吗？

4

4 回答 4

7

不知道 Gradle 的细节，因为我是一个 Maven 人，但无论如何这更通用。你基本上有两个选择（而且都是hacky）：

  1. 类加载器魔术。不知何故，您需要说服您的构建系统加载两个版本的库（祝您好运），然后在运行时，使用具有旧版本的 ClassLoader 加载使用旧版本的类。我已经这样做了，但这很痛苦。（像 OSGI 这样的工具可能会消除一些这种痛苦）
  2. 包底纹。重新打包使用旧版本库 B 的库 A，使 B 实际上在 A 内部，但带有 B 特定的包前缀。这是常见的做法，例如 Spring 发布了自己的 asm 版本。在 Maven 方面，maven-shade-plugin执行此操作，可能有一个 Gradle 等价物。或者你可以使用ProGuard，这个 800 磅重的 Jar 操作大猩猩。
于 2016-04-29T14:27:26.120 回答
2

Gradle 只会使用您的依赖项设置类路径，它不提供自己的运行时来封装依赖项及其传递依赖项。在运行时活动的版本将是根据类加载规则的版本，我相信这是类路径中包含该类的第一个 jar。OSGI 提供了可以处理此类情况的运行时，即将推出的模块系统也是如此。

编辑：Bjorn 是对的，它会尝试解决不同版本的冲突；它将根据其策略编译类路径，因此您将依赖项放入文件中的顺序无关紧要。但是，每个类名您仍然只能获得一个类，它不会解决 OP 的问题

于 2016-04-29T14:18:28.730 回答
0

更糟糕的情况是同一个类出现在多个 jar 中。这更加阴险 - 查看 Codahale 和 Dropwizard 的指标 jars，这两个 jars 中同一类的版本不兼容。gradle classpath-hell 插件可以检测到这种恐怖。

于 2017-03-06T23:13:44.287 回答
0

如果您有不同版本的库具有相同的坐标，Gradles 冲突解决机制就会发挥作用。

默认的解析策略是使用最新请求的库版本。您不会在依赖图中获得同一库的多个版本。

如果您在运行时确实需要同一库的不同版本，您将不得不做一些绝对可能的 ClassLoader 魔术，或者为其中一个库或两者都做一些阴影。

关于冲突解决，Gradle 内置了最新的默认策略和失败策略，如果依赖关系图中的不同版本并且您必须在构建文件中显式解决版本冲突，则该策略会失败。

于 2016-04-29T14:56:35.737 回答