Подтвердить что ты не робот

Gradle версии зависимостей + знак

Я пытаюсь понять, как Gradle обрабатывает версии зависимостей с знаком "+", как показано в примере 8.1 здесь: http://www.gradle.org/docs/current/userguide/artifact_dependencies_tutorial.html

testCompile group: 'junit', name: 'junit', version: '4.+

В документации указано, что это получит версию junit >= 4.0. Как получить версию зависимости больше (или равна), скажем, 5.10? Это будет 5.10+ или 5.1+? Первый, похоже, работает неправильно, но последний делает это. Как получить зависимость, большую или равную 1,22? 1.2+? В этом случае, если версия 1.21 существует и является последней версией, я хотел бы сбой, так как я хочу больше или равно 1.22, но 1.2+ будет искать >= 1.20. Как я могу это указать? Это возможно? Я не могу найти больше документации.

Изменить: я склонен думать об этом, поскольку 1.2+ эквивалентен 1.2([0-9]+). Это правильный способ мышления?

4b9b3361

Ответ 1

В этом случае, если версия 1.21 существует и является последней версией, я хотел бы потерпеть неудачу, так как я хочу больше или равно 1,22, но 1.2+ будет искать >= 1.20. Как я могу это указать? Возможно ли это?

Я не думаю, что есть документация об этом, но поскольку Gradle изначально использовал Ivy под капотом для всех своих функций управления зависимостями, я взглянул на документацию Ivy относительно динамических версий:

http://ant.apache.org/ivy/history/latest-milestone/ivyfile/dependency.html

Он имеет лишь немного больше, чем документация Gradle. Я пробовал экспериментировать в Gradle с диапазонами версий в стиле Ivy:

compile group: 'log4j', name: 'log4j', version: '[1.2.12,1.2.17]'

и, как ни странно, иногда он работает в зависимости от диапазона версии. В приведенном выше примере он разрешает 1.2.17.

Я знаю, что это не полностью затрагивает ваши вопросы (что мне тоже интересно), но, надеюсь, он предоставит вам немного информации.

Ответ 2

Я думаю, проблема в том, что вы неправильно думаете о "+" в терминах регулярного выражения. Он не предназначен для чтения как элемент выражения регулярного выражения ( "один или несколько числовых символов" ), а скорее как "последняя доступная версия, где каждый из ведущих компонентов SEMVER соответствует предоставленному шаблону". Ссылки на то, почему это не предпочтительнее даже использовать эту нотацию, можно найти по адресу: http://central.sonatype.org/articles/2014/Oct/28/enforcing-valid-dependency-versions/