Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use TOML Versions Catalogs instead of dependencies.gradle.kts #13790

Closed

Conversation

jamesonwilliams
Copy link
Contributor

@jamesonwilliams jamesonwilliams commented Nov 16, 2024

Contributor checklist

  • I am following the Code Style Guidelines
  • I have tested my contribution on these devices:
    • This is a build level change, no testing on device
  • My contribution is fully baked and ready to be merged as is
  • I ensure that all the open issues my contribution fixes are mentioned in the commit message of my first commit using the Fixes #1234 syntax

Background

Currently, the project uses a monolithic dependencies.gradle.kts to specify dependency versions. This is not so bad, and the libraries are nicely split up into separate catalogs. (Tasteful!)

However, there is no IDE integration when specifying dependencies this way, so you see this in Android Studio:

Screenshot 2024-11-15 at 7 32 13 PM

This means you miss out on visual queues about out-of-date dependencies, etc.

As of Gradle 7.0, Gradle has been endorsing a different way of specifying dependencies, by using .toml version catalog files. These have good IDE integration, so you can see guidance around out-of-date dependencies and even get suggestions under the Project Settings:

Screenshot 2024-11-15 at 7 36 20 PM Screenshot 2024-11-15 at 7 36 04 PM

Approach

To make sure I faithfully copied each dependency over to the new file format, I wrote a sloppy Python script that parsed each line with some regexes and then spit out the new format.

After I did this, resolved miscellaneous issues, and validated ./gradlew qa still passes, I remove dependencies that were not being referenced anywhere (these are easy to spot now because the IDE tells you about them).

Testing

While I was going about this, I wanted to ensure two things were true:

  1. I could continue to use the four separate catalogs (now, this is done by using four .toml files:
    a. libs.versions.toml
    b. test-libs.versions.toml
    c. lint-libs.versions.toml
    d. benchmark-libs.versions.toml
  2. That the dependency verification stuff still works.

(1) was not initially true; I had to manually register the non-libs toml files in the projects' two settings.gradle.kts. But, after doing that, I was able to build the project without updating any other Gradle build files that make references to the existing catalogs.

To validate (2), I tried updating a dependency from the IDE auto-suggestions and then running ./gradlew qa. It fails as intended:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':Signal-Android:mergePlayProdReleaseArtProfile'.
> Dependency verification failed for configuration ':Signal-Android:playProdReleaseRuntimeClasspath'
  3 artifacts failed verification:
    - annotations-4.16.0.module (com.github.bumptech.glide:annotations:4.16.0) from repository MavenRepo
    - gifdecoder-4.16.0.aar (com.github.bumptech.glide:gifdecoder:4.16.0) from repository MavenRepo
    - glide-4.16.0.aar (com.github.bumptech.glide:glide:4.16.0) from repository MavenRepo

@greyson-signal
Copy link
Contributor

This is great, I actually did a side project recently and learned how much better toml files are treated by the IDE. I had been meaning to move us over to toml eventually, so thank you for doing it for us!

@jamesonwilliams
Copy link
Contributor Author

Woohoo, it's in; will close this PR

https://github.com/signalapp/Signal-Android/tree/main/gradle

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants