I made a deal with the Gradle build system

Photo by Debby Hudson on Unsplash

I have always been a consumer of technical blogging, it’s my first time to be a producer, (or publicly at least, I write articles inside Swvl where I work currently) so pardon my noviceness ^^

Intro

This is the first article of series of articles that will be discussing the challenges we faced, options we had, and why we landed on which option during building our side project.

When we were building our side project with my teammate, Nageh, I was assigned to research methodologies for implementing a centralized grade dependency.

Well, if it’s just about this, then BuildSrc will pop up in your mind, right?

It wasn’t just about this, the other goal we were aiming for is to have dependabot support for keeping those dependencies up to date and hassle-free…

The Problem

So here is the problem: dependabot’s support for Gradle build systems is still in its early stages, it does not support BuildSrc based dependency system yet (more followup here) it only supports scanning the build.gradle files statically (added support to scan build.gradle.kts files also).

So you will get this up and running only if you keep your dependencies and their versions in the same build.gradle file, and we can’t do that as we want to have a centralized location where we can manage and update them across modules.

So let’s gather the pros and cons of our options here:

BuildSrc:

Pros:

1. A centralized approach to manage gradle dependencies.
2. Have the support of our beloved Kotlin ❤️, so you will get auto-complete and you will get to manage your dependencies with a statically typed language.

Cons:

1. Dependabot, you’re out!
2. You can’t also get Android Studio prompts for version updates.
3. The Gradle build cache does not support BuildSrc, so the build cache of your entire project will be invalidated if you changed a single line in your dependency file.

Gradle default setup:

Pros:

1. It has dependabot support.
2. You will get to use Android Studio prompts about version updates.
3. It will use the Gradle cache to skip already built modules.

Cons:

1. It is not centralized, and no unified dependency versioning across all your modules.
2. It does not have our beloved kotlin support (no auto-complete, etc).

The Deal!

So, what about getting some of the pros of both? Sounds like a good deal, right?

Gradle Extra Properties FTW!

Using GEP, you will get to define and manage all your project dependencies from one place (build.gradle project file) and since this file is visible to all project modules, it will be the perfectly centralized place. And you will get dependabot help on keeping them up to date. Plus it’s the recommended approach by Google. Here is a sample of your deal’s outcome:

Root project’s build.gradle file

app module build.gradle file

We will get the pros of having a centralized approach to manage Gradle dependencies and the support of dependabot. What can an engineer wish more, huh?

If you made it that far, thank you! ^_^