An argument against buildSrc-defined dependencies (or: how to seamlessly keep your Gradle dependencies up to date on Github)

3 min readAug 16, 2020

Managing dependencies is crucial for every project, especially those with large number of them included in many modules. The important part of managing is taking care of updates in order to decrease progressive tech debt. I find below conference keynote by Eileen M. Uchitelle as a great example of what can be the cost of, maybe sometimes unaware, neglected tech debt:

How to keep your Gradle-based project dependencies up to date?

Github recently announced Dependabot version updates system. This tool can automatically scan for dependencies defined in build.gradle files and create a pull request with a version update:

https://github.com/wzieba/BuildSrcVsGradleExtraProperties/pull/2

For the detailed configuration possibilities, like scan intervals, max pull request count and more go to the official documentation.

This is great for two reasons: firstly, it’ll reduce the time of developers by reminding about updates and even creating simple PRs which, in case of no errors thrown by your CI/CD system, might be assumed as valid and safe (especially minor/patch bumps). Secondly, if the configuration won’t limit number of open PRs, it’ll increase awareness of tech debt. Having one or two dependencies that are not up to date might not be a problem, but seeing ~20 open PRs might scare any developer and/or project manager. I believe, a massive number of open PRs created by Dependabot can emphasize the problem and be helpful in any negotiations on the importance and need of taking care of strictly technical aspects of the project.

Limitations? You can’t use Dependabot

This works really great but comes with one major limitation: currently, you can’t use this bot when defining dependencies under buildSrc directory. The Github issue has been reported, but since March 2019 nothing has changed: https://github.com/dependabot/dependabot-core/issues/2180.

It shouldn’t stop us to use Dependabot though. Furthermore: I would advise to every Gradle-based project to drop buildSrc support for declaring dependencies and use Gradle Extra Properties instead, which is a suggested way of managing dependencies by Android.

Let’s rewind and remind ourselves why do we use buildSrc :

Pros of defining dependencies under buildSrc directory

Many Gradle-based projects use buildSrc directory, which is treated as included build. Its easier to write and maintain configuration code in strongly typed JVM languages like Java or Kotlin, especially for writing custom tasks or plugins. That’s why Gradle docs stand to favor buildSrcover any script code:

buildSrc should be preferred over script plugins as it is easier to maintain, refactor and test the code. ~ source: docs.gradle.org

But the majority of projects I’ve seen, use buildSrc only to provide and maintain dependencies definitions. What is the main, and I believe the only argument? The answer is: autocompletion

Auto-completion when using `buildSrc` defined dependencies

Browsing through the articles I couldn’t find any other argument than this.

Cons of buildSrc dependencies

You can’t use Android Studio prompts

If dependencies are defined as plain-text or by Gradle Project Extensions, the Android Studio build-in prompt system will inform about any update. It will highlight any outdated dependencies as well as suggest version bump.

2. You can’t use Dependabot

And this was dealbreaker for me. As mentioned above, Dependabot can only scan for dependencies that are declared as plaintext or declared with Gradle Extra Properties: https://github.com/dependabot/feedback/issues/392

Sweetspot? Use Gradle Extra Properties

With GEP you have access to Android Studio prompt as well as Dependabot tool. What you loose is only code autocompletion, which sounds as very little lose compared to unlocking tools for automated tech-debt reduction.

Or is there anything I’ve missed? Do you use buildSrc for dependency management? If so, is there anything more than just code autocompletion comparing to Gradle Extra Properties?