#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 в скрипте сборки, чтобы поддерживать его единообразие с другими зависимостями. Если бы у каждой платформы был свой собственный плагин для управления зависимостями, ну, это было бы довольно беспорядочно, нет?