DevOps / Gradle8 Interview Questions
When should you use a version catalog instead of hardcoded dependency strings?
A version catalog (gradle/libs.versions.toml) centralizes dependency coordinates and versions in one shared file that every subproject's build script references by alias, rather than each module hardcoding its own 'group:artifact:version' string.
# gradle/libs.versions.toml [versions] junit = "5.10.2" [libraries] junit-jupiter = { module = "org.junit.jupiter:junit-jupiter", version.ref = "junit" }
dependencies { testImplementation libs.junit.jupiter }
It's worth adopting as soon as a build has more than a couple of modules sharing common dependencies, since without it, bumping a shared library's version means hunting down every hardcoded occurrence across every module's build file. With a catalog, that same bump is a one-line change in the TOML file, and type-safe accessors (libs.junit.jupiter) also catch a typo'd alias at build-script compile time rather than failing later during dependency resolution.
What problem does a version catalog solve in a multi-module project?
In what file format is a Gradle version catalog typically defined?
More Related questions...
