How to detect when dependency library version upda

Question

I've an android project with two modules (typical front-end app and backend). I have three build.gradle files, one in each module and one in the root.

The way I've structured my dependencies is by extracting all the versions into separate variables in the root level build.gradle as such

ext {
    // SDK and tools
    MIN_SDK_VERSION = 19
    TARGET_SDK_VERSION = 23
    COMPILE_SDK_VERSION = 23
    BUILD_TOOLS_VERSION = '24'

    // app dependencies
    GOOGLE_API_CLIENT_VERSION = '1.19.0'
    GOOGLE_PLAY_SERVICES_VERSION = '8.4.0'
    ANDROID_SUPPORT_LIB_VERSION = '23.1.0'
    [...]

    // backend dependencies
    [...]
}

which are later used in my say app build.gradle file as such

dependencies {
    [...]
    compile(group: 'com.google.oauth-client', name: 'google-oauth-client', version: rootProject.ext.GOOGLE_API_CLIENT_VERSION)
    /////////////////////////////////
    // Google Play Services explicit dependency
    compile(group: 'com.google.android.gms', name: 'play-services-auth', version: rootProject.ext.GOOGLE_PLAY_SERVICES_VERSION)
    compile(group: 'com.google.android.gms', name: 'play-services-plus', version: rootProject.ext.GOOGLE_PLAY_SERVICES_VERSION)
    [...]

    /////////////////////////////////
    // Local Testing
    testCompile(group: 'junit', name: 'junit', version: rootProject.ext.JUNIT_VERSION)
    testCompile(group: 'pl.pragmatists', name: 'JUnitParams', version: rootProject.ext.JUNIT_PARAMS_VERSION)
    [...]
}

NOTE: I found that idea in a tutorial somewhere and I thought it was very nifty.

However, I'm struggling to keep track of which lib versions are available, what is upgradable, etc. It is becoming hard to keep track of these things as I have a reasonably sized list of dependencies. Curious how others have approached this problem. Thanks.

Answer 1

A summary of how I manage dependencies.

All dependency definitions are defined in gradle/dependencies.gradle, which is applied to all projects and the buildscript. I usually break it into three categories. A full example is here.

ext {
  versions = [
    caffeine: '2.3.1',
  ]
  test_versions = [
    testng: '6.9.12',
  ]
  plugin_versions = [
    versions: '0.13.0',
  ]

  libraries = [
    caffeine: "com.github.ben-manes.caffeine:caffeine:${versions.caffeine}",
  ]
  test_libraries = [
    testng: dependencies.create("org.testng:testng:${test_versions.testng}") {
      exclude group: 'junit'
    },
  ]
  gradle_plugins = [
    versions: "com.github.ben-manes:gradle-versions-plugin:${plugin_versions.versions}",
  ]
}

Then in my root project I bootstrap it as,

buildscript {
  apply from: "${rootDir}/gradle/dependencies.gradle"

  repositories {
    jcenter()
  }

  dependencies {
    gradle_plugins.each { name, dependency -> classpath dependency }
  }
}

allprojects {
  apply from: "${rootDir}/gradle/dependencies.gradle"

  repositories {
    jcenter()
  }
}

This allows defining the dependency in a project as,

dependencies {
  compile libraries.caffeine
}

To detect newer versions I wrote the gradle-versions-plugin. That generates a report by querying the repositories for the version information and comparing it to your definitions. I run it manually every so often, but others script it in their CI and use the json or xml reports.

There are a few other approaches that were developed after I wrote my plugin. Spring's dependency-management-plugin works with Maven BOMs, as does Netfix's nebula-dependency-recommender-plugin. Netflix uses gradle-dependency-lock-plugin to define dynamic versions and generate a lock file to fix a release. There are also dependency version alerting services, though a simple CI job is likely equivalent.

I've never used any of the alternatives as they seem less intuitive (to me), came out years after I had a nice solution, and it is a familiar approach if you come from Maven. Hopefully someone else can shed light on the benefits of other approaches.