Как установить версию зависимостей на gradle?

Хочу в конфигурационный файл установить версию моих зависимостей только в одном месте в моем Gradle(приложение / build.gradle), чтобы было проще менять в случае обновления.

проблема в:

dependencies {
implementation 'com.google.android.gms:play-services-maps:12.0.0'
implementation 'com.google.android.gms:play-services-auth:12.0.0'
implementation 'com.google.firebase:firebase-core:12.0.0'
implementation 'com.google.firebase:firebase-auth:12.0.0'
implementation 'com.google.firebase:firebase-database:12.0.0'
implementation 'com.google.firebase:firebase-storage:12.0.0'
implementation 'com.google.firebase:firebase-messaging:12.0.0'
implementation 'com.google.android.gms:play-services-ads:12.0.0'
implementation 'com.github.bumptech.glide:glide:4.5.0'
}

Вы видите, что я повторяю одну и ту же версию много раз, и это делает медленным и непродуктивным изменение всех версий на следующую.

Как и в Maven, я мог сделать вот так:

<properties>
    <org.springframework.version>5.0.8.RELEASE</org.springframework.version>
</properties>

После установки версии я просто добавляю вот так:

<dependencies>
    <!-- Spring -->
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
        <version>${org.springframework.version}</version>
    </dependency>
</dependencies>

Последняя часть конфигурации Maven установила версию в этой части:

${org.springframework.version}

Как я могу сделать то же самое в моей конфигурации Gradle?

1
0
833
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

категорически неверно предположение, что у всех была бы одна и та же версия ...

def glideVersion = "4.5.0"

dependencies {

    implementation "com.google.android.gms:play-services-base:16.0.1"
    implementation "com.google.android.gms:play-services-auth:16.0.1"

    implementation "com.google.android.gms:play-services-maps:16.0.0"
    implementation "com.google.android.gms:play-services-ads:16.0.0"

    implementation "com.google.firebase:firebase-core:16.0.4"
    implementation "com.google.firebase:firebase-auth:16.0.4"

    implementation "com.google.firebase:firebase-database:16.0.3"
    implementation "com.google.firebase:firebase-storage:16.0.3"

    implementation "com.google.firebase:firebase-messaging:17.3.4"

    implementation "com.github.bumptech.glide:glide:${glideVersion}"
}

можно также установить project.extхарактеристики с номерами версий - или загрузить их из внешних файлов.

ext {
    glideVersion = "4.5.0"
    ...
}

а затем используйте его с ${rootProject.ext.glideVersion} или ${project.ext.glideVersion}.

в общем, поменять не проще ... просто другой способ организации.

@Dims, как уже было сказано в предыдущих комментариях, вам нужны двойные кавычки " ... по крайней мере, при оценке выражений. stackoverflow.com/questions/15171049/…

Martin Zeitler 28.10.2018 09:31

Хорошо, спасибо, это сработало. Также не могли бы вы объяснить, почему в одном контексте nd4j_version и "${nd4j_version}" относятся к разным переменным?

Dims 28.10.2018 09:38

@Dims может только догадываться, не видя скрипта, но def определяет локальную переменную, которая может быть определена с другим значением в другой области. в пределах одной и той же области он всегда должен быть одинаковым.

Martin Zeitler 28.10.2018 10:12

Я ссылаюсь на ваш код. Вы написали ext { glideVersion, но в строках вы написали ${project.ext.glideVersion}, а не ${ext.glideVersion}. У вас есть exta nesting, нигде не указано. Почему?

Dims 28.10.2018 10:36

И почему вы не написали ext { def glideVersion = ?

Dims 28.10.2018 10:38

@Dims, потому что один определяет дополнительные свойства проекта Gradle, а другой - локальную переменную Groovy. groovy-lang.org/documentation.html (Gradle DSL основан на этом).

Martin Zeitler 28.10.2018 10:52

Вопрос не в определении, а в использовании. Почему путь в строке раскрытия отличается от пути при прямом использовании (для того же способа определения)

Dims 28.10.2018 14:37

@Dims, потому что это корневой проект и подпроект (модуль), каждый из которых имеет свои собственные «дополнительные свойства» ext. в зависимости от того, где вы определяете переменные / свойства, нужно ссылаться на них соответственно. например. можно даже определить локальные переменные в подпроекте и инициализировать их дополнительными свойствами корневого проекта. здесь я часто использую файл version.properties, который загружаю в корневой проект, а затем ссылаюсь в подпроектах (которые я считаю наиболее организованным способом управления номерами версий).

Martin Zeitler 29.10.2018 02:37

Другие вопросы по теме