When defining the dependencies for a Gradle project, such as an Android app, there are situations that call for duplicated information. A common case is that libraries or plugins can often come with multiple dependencies, which are usually released together with matching versions. Maintaining these dependencies requires the version to be duplicated and then kept up-to-date as new versions are released. Another case is that it is common to have a multi-module project, where we may want a dependency to be added to multiple modules. Similarly to the case with versions, the dependency definition would be duplicated for each module and then kept in-sync moving forward. It is clear that in both cases we may want to define the dependencies in one place and then access this location from wherever the dependency definition is needed.

The Groovy way

There is a mechanism for sharing your dependency configuration using Groovy, by adding some extra properties in our root build.gradle file. This is Google’s recommended solution and can be nicely seen in practice within the SdkSearch app by Jake Wharton, which works in a similar way to the following Gradle script snippets.

→ /build.gradle

buildscript {
  ext.versions [
    'kotlin': '1.3.10',
    'dagger': '2.19'
  ]

  ext.deps [
    'kotlin': [
      'stdlib': "org.jetbrains.kotlin:kotlin-stdlib:${versions.kotlin}",
      'test': "org.jetbrains.kotlin:kotlin-test-common:${versions.kotlin}"
    ],
    'dagger': [
      'runtime': "com.google.dagger:dagger:${versions.dagger}",
      'compiler': "com.google.dagger:dagger-compiler:${versions.dagger}",
      'androidRuntime': "com.google.dagger:dagger-android:${versions.dagger}",
      'androidCompiler': "com.google.dagger:dagger-android-processor:${versions.dagger}",
    ]
  ]
}

→ /app/build.gradle

dependencies {
  implementation deps.kotlin.stdlib

  implementation deps.dagger.runtime
  implementation deps.dagger.androidRuntime
  kapt deps.dagger.compiler
  kapt deps.dagger.androidCompiler

  testImplementation deps.kotlin.test
}

Sharing the configuration via the root build.gradle file achieves the goal of having a single location to maintain. Only needing to update dependency versions in a single file is a great time-saver as well 🚀. Unfortunately from practice, when using the Groovy Gradle DSL auto-complete is often missing or incomplete in this situation, making it awkward to use. On top of this, Gradle 5.0 is on the horizon which includes the production-ready Kotlin Gradle DSL. When we convert the above solution to Kotlin it isn’t as nice to use in Kotlin as it is in Groovy. The map syntax can be achieved using mapOf, but reading the data to pass to implementation requires some casting to fit with the statically typed language. 😢

Kotlin to the rescue

As many developers have found with their main app source code, Kotlin can help with defining our dependency configurations as well, even if we have Groovy-based Gradle scripts.

Kotlin and Gradle - a match made in heaven?
Kotlin and Gradle - a match made in heaven?

When ran, Gradle will check for a buildSrc directory in the root of the project, placing any code that is found into the classpath of our build. This is really handy and allows us to put Kotlin code into buildSrc and then reference it from our Groovy scripts. To get started we just need a little bit of structure.

→ /buildSrc/build.gradle.kts

plugins {
  `kotlin-dsl`
}

The Kotlin DSL plugin needs to be specified for buildSrc.

→ /buildSrc/src/main/java/com/ourapp/Versions.kt

Our source files need to be placed within the standard sources directory structure. To use inner objects, for now we need to include the sources within a package, e.g. ‘com.ourapp’.

package com.ourapp

object Versions {    
  object Gradle {
    const val KTLINT = "0.29.0"
  }

  const val DAGGER = "2.19"  
  const val KOTLIN = "1.3.10"  
}

→ /buildSrc/src/main/java/com/ourapp/Libs.kt

package com.ourapp

object Libs {
  object Gradle {
    const val KTLINT = "com.github.shyiko:ktlint:${Versions.Gradle.KTLINT}"
  }

  object Dagger {  
    const val RUNTIME = "com.google.dagger:dagger:${Versions.DAGGER}"  
    const val COMPILER = "com.google.dagger:dagger-compiler:${Versions.DAGGER}"  
    const val ANDROID_RUNTIME = "com.google.dagger:dagger-android:${Versions.DAGGER}"  
    const val ANDROID_COMPILER = "com.google.dagger:dagger-android-processor:${Versions.DAGGER}"  
  }    

  object Kotlin {  
    const val STDLIB = "org.jetbrains.kotlin:kotlin-stdlib:${Versions.KOTLIN}"
    const val TEST = "org.jetbrains.kotlin:kotlin-test-common:${Versions.KOTLIN}"
  }  
}

→ /app/build.gradle

Once Gradle has been synced, we can now reference our dependencies within our Groovy scripts. This is pretty much the same as we used with the Groovy extra properties solution above.

import com.ourapp.Libs

dependencies {
  implementation Libs.Kotlin.STDLIB

  implementation Libs.Dagger.RUNTIME  
  implementation Libs.Dagger.ANDROID_RUNTIME  
  kapt Libs.Dagger.COMPILER  
  kapt Libs.Dagger.ANDROID_COMPILER

  testImplementation Libs.Kotlin.TEST

  ktlint Libs.Gradle.KTLINT
}

Using buildSrc and Kotlin sources achieves the goal of having a single location to maintain and we can even reduce it to a single Kotlin source file if it makes sense to. The solution can be used in the same way from both Groovy and Kotlin Gradle DSL without being altered, which frees us up to change our Gradle scripts to Kotlin if we want to. The best thing about defining dependencies in this way is that we get access to effective auto-complete and being able to click through to where a dependency is defined from our Gradle scripts, super useful. 🙌

Final thoughts

Naturally, for the reasons given I prefer to use the buildSrc and Kotlin source approach in my Android projects. I am very much looking forward to being able to use Gradle 5.0 on Android and have all my Gradle scripts using the Kotlin DSL.

What do you think of managing dependencies in this way? Do you already do it or do you have any thoughts on a way to improve it further? Please feel free to reach out to me on Twitter @lordcodes with any questions or thoughts you have, or about anything else.

If you like what you have read, please don’t hesitate to share the article and subscribe to my feed if you are interested.

Thanks for reading and happy coding! 🙏