Какова логика разрешения зависимостей Gradle

В Gradle 6.7 у нас есть dependencyManagement.dependencies для установки значений по умолчанию для проекта.

Недавно кто-то заменил отдельные строки dependency для Spring строкой dependencySet.

dependencySet(group: 'org.springframework.boot', version: "2.2.11.RELEASE") {
            entry 'spring-boot-devtools'
            entry 'spring-boot-dependencies'
            entry 'spring-boot-devtools'
            entry 'spring-boot-starter-aop'
            entry 'spring-boot-starter-cache'
            entry 'spring-boot-starter-webflux'
            ...

Теперь, обнаружив несколько предупреждений CVE, я обнаружил, что Gradle все равно разрешает spring-boot-starter-cache в 2.2.8. Я не уверен, откуда он берет эту версию: у нас ее нет в нашем проекте, и дерево зависимостей выглядит так, как будто мы сами его запросили (оно на уровне 0).

+--- org.springframework.boot:spring-boot-starter-cache -> 2.2.8.RELEASE

Когда я добавляю элемент явно, как раньше для всех,

dependency 'org.springframework.boot:spring-boot-starter-cache:2.2.11.RELEASE'

затем он разрешается как 2.2.11.

+--- org.springframework.boot:spring-boot-starter-cache -> 2.2.11.RELEASE

В Maven управление зависимостями очень простое по сравнению с этим: вы управляете им с помощью управления зависимостями и спецификаций, и все работает, никаких сюрпризов.

Так что, возможно, я что-то упустил в логике Gradle, даже после прочтения руководства по управлению зависимостями.

Как я могу использовать dependencySet, похожий на спецификацию, для одновременного управления всеми entry? Или у меня неправильные предположения?


gradle gradle-dependencies dependency-management
person Ondra Žižka    schedule 12.11.2020    source источник

Ответы (1)


arrow_upward
1
arrow_downward

В Gradle 6.7 у нас есть dependencyManagement.dependencies для установки значений по умолчанию для проекта.

Не путайте весенний плагин Gradle для управления зависимостями с Собственная функция Gradle для управления зависимостями. Несмотря на то, что они достигают одной и той же цели, они делают это очень разными способами.

Я не уверен, откуда он берет эту версию: у нас ее нет в нашем проекте, и дерево зависимостей выглядит так, как будто мы сами его запросили (оно на уровне 0).

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

./gradlew dependencyInsight --dependency org.springframework.boot:spring-boot-starter-cache

Дополнительные сведения см. в разделе Просмотр и отладка зависимостей .

Как я могу использовать dependencySet, похожий на спецификацию, для одновременного управления всеми entry? Или у меня неправильные предположения?

Документы для плагина управления зависимостями Spring ясно показывают, что вам нужно сделать для этого: https://docs.spring.io/dependency-management-plugin/docs/current/reference/html/#dependency-management-configuration-dsl-dependency-sets

Если это не работает так, как вы ожидаете, вам нужно отладить свои зависимости, как я указал выше.

Также из ваших примеров я предполагаю, что у вас есть типичное приложение Spring Boot с примененным плагином Spring Boot Gradle. Если это так, то подключаемый модуль Spring Boot Gradle определяет, применяется ли подключаемый модуль управления зависимостями Spring, и spring-boot-tools/spring-boot-gradle-plugin/src/main/java/org/springframework/boot/gradle/plugin/DependencyManagementPluginAction.java#L36" rel="nofollow noreferrer">автоматически импортирует спецификацию Spring Boot< /а>. Таким образом, не должно быть необходимости управлять специфическими зависимостями Spring, как вы.

person Francisco Mateo    schedule 13.11.2020
comment
Спасибо Франциско! Похоже, нужно проверить довольно много вещей - у нас есть внутренняя структура, которая делает некоторые вещи, которые вы упомянули, но тогда это только зависимость нашего проекта, в отличие от родителя Maven. Поэтому я ожидаю, что это будет просто еще один источник переходных зависимостей. Я бы предпочел управлять зависимостями в сценарии сборки, чтобы он оставался единым с другими зависимостями. Если бы у каждого фреймворка был свой плагин для управления зависимостями, это был бы настоящий беспорядок, не так ли? - person Ondra Žižka; 25.11.2020