версия транзитивной зависимости gradle force не работает.Кажется, не применяется исключение, переопределение или форсирование - PullRequest
0 голосов
/ 30 мая 2018

У меня конфликт с переходной зависимостью.Переопределение, исключение или форсирование не помогают.Что еще я могу сделать, чтобы получить правильную версию библиотеки в банку?Полный код может быть.найдено https://github.com/geoHeil/gradle-dependency-resolution, но основные его части описаны ниже.

описание проблемы

выполнение

./gradlew shadowJar

с зависимостями geomesa (что приводит к устареваниюверсия библиотеки конфигурации typesafe / lightbend) отключена:

dependencies {

    compile "com.github.kxbmap:configs_2.11:0.4.4"
    //compile "org.locationtech.geomesa:geomesa-hbase-spark-runtime_2.11:2.0.1"
}

и выполнение jar

java -jar build/libs/gradleThing-all.jar                         

выводит

hello
my config is: Success(Job1Configuration(frequencyCounting))

При включении зависимостей:

./gradlew shadowJar
java -jar build/libs/gradleThing-all.jar                         

происходит сбой с

hello
Exception in thread "main" java.lang.Exception: Failed to start. There is a problem with the configuration: Vector([extract] com.typesafe.config.Config.hasPathOrNull(Ljava/lang/String;)Z)

, что связано с устаревшей версией библиотеки конфигурации, как разрешить NoSuchMethodError в типах безопасной конфигурации? .Также подтверждено с помощью:

gradle dependencyInsight --dependency om.typesafe:config

> Task :dependencyInsight
com.typesafe:config:1.3.1 (conflict resolution)
   variant "runtime" [
      Requested attributes not found in the selected variant:
         org.gradle.usage = java-api
   ]
\--- com.github.kxbmap:configs_2.11:0.4.4
     \--- compileClasspath

com.typesafe:config:1.2.1 -> 1.3.1
   variant "runtime" [
      Requested attributes not found in the selected variant:
         org.gradle.usage = java-api
   ]
+--- org.locationtech.geomesa:geomesa-convert-avro_2.11:2.0.1
|    \--- org.locationtech.geomesa:geomesa-convert-all_2.11:2.0.1
|         +--- org.locationtech.geomesa:geomesa-tools_2.11:2.0.1
|         |    \--- org.locationtech.geomesa:geomesa-hbase-spark-runtime_2.11:2.0.1
|         |         \--- compileClasspath
...

Как я могу исправить переходную зависимость для желаемой версии 1.3.3?

мои решения

Пытаться установить:

compile("org.locationtech.geomesa:geomesa-hbase-spark-runtime_2.11:2.0.1") {
                exclude group: 'com.typesafe', module: 'config'
            }

и повторный запуск банки завершается неудачно с той же проблемой.

Также ограничение https://docs.gradle.org/current/userguide/managing_transitive_dependencies.html#sec:dependency_constraints, например:

implementation("com.typesafe:config")
    constraints {
        implementation("com.typesafe:config:1.3.3") {
            because 'previous versions miss a method https://stackoverflow.com/questions/40610816/how-to-resolve-nosuchmethoderror-on-typesafe-config'
        }
    }

или использование силы https://docs.gradle.org/current/userguide/managing_transitive_dependencies.html#sec:enforcing_dependency_version как:

implementation('com.typesafe:config:1.3.3') {
        force = true
    }

или как:

configurations.all {
    resolutionStrategy {
        force 'com.typesafe:config:1.3.3'
    }
}

не дает правильную версию.

результат

Все варианты завершаются неудачно ста же ошибка

Что не так?Должен быть способ форсировать желаемую версию.

1 Ответ

0 голосов
/ 30 мая 2018

Проблема, с которой вы столкнулись, является полной противоположностью того, что вы описываете.

Все разные вещи, которые вы пробовали в своем проекте, гарантируют, что версия com.typesafe:config будет 1.3.x.

Однако при добавлении org.locationtech.geomesa:geomesa-hbase-spark-runtime_2.11:2.0.1 вы получаете некоторую зависимость, которая уже имеет классы из com.typesafe:config, но из строки 1.2.И когда вы создаете свой толстый сосуд, эта версия перезаписывает классы из строки 1.3.

Это можно увидеть, распаковав ваш толстый сосуд и запустив:

$ javap com/typesafe/config/Config.class | grep hasPath
  public abstract boolean hasPath(java.lang.String);

, показывая, что это действительноhasPathOrNull метод отсутствует.

Об этой проблеме с затенением намекают в https://issues.apache.org/jira/browse/SPARK-9441.

Учитывая это, легкий путь - если возможно для вас - будет понизить "com.github.kxbmap:configs_2.11 доверсия, основанная на com.typesafe:config:1.2.x

Другое решение состоит в том, чтобы выяснить, какие именно жировые банки включают в себя эти, и посмотреть, можете ли вы исключить их из своей собственной жировой банки.

...