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

#gradle #dependency-management #gradle-dependencies

#gradle #управление зависимостями #gradle-зависимости

Вопрос:

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

Недавно кто-то заменил отдельные dependency строки для Spring на a 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 в любом случае разрешает. Я не уверен, откуда он берет эту версию: у нас ее нет в нашем проекте, и дерево deps отображается так, как будто мы сами просили об этом (оно на уровне 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, даже после прочтения руководства по управлению зависимостями.

Как я могу использовать BOM-like dependencySet для одновременного управления всеми entry ? Или у меня неправильные предположения?

Ответ №1:

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

Не путайте плагин Gradle для управления зависимостями Spring с встроенной функцией управления зависимостями Gradle. Хотя они достигают одной и той же цели, они делают это совершенно по-разному.

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

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

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

Более подробную информацию см. в разделе Просмотр и отладка зависимостей.

Как я могу использовать BOM-like dependencySet для одновременного управления всеми entry ? Или у меня неправильные предположения?

В документах для плагина Spring dependency management ясно, что вам нужно сделать для достижения этой цели: 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 dependency management, и автоматически импортирует спецификацию Spring Boot. Таким образом, не должно быть необходимости управлять зависимостями, специфичными для Spring, как вы.

Комментарии:

1. Спасибо, Франциско! Похоже, довольно много вещей для проверки — у нас есть внутренняя структура, которая выполняет некоторые из упомянутых вами действий, но тогда это всего лишь зависимость нашего проекта, в отличие от родительского Maven. Так что я бы ожидал, что это будет просто еще одним источником переходных зависимостей. Я бы предпочел управлять deps в скрипте сборки, чтобы поддерживать его единообразие с другими зависимостями. Если бы у каждой платформы был свой собственный плагин для управления зависимостями, ну, это было бы довольно беспорядочно, нет?