Versions and Catalogs
Where versions are declared and how they are expressed: version catalogs, platforms and BOMs, dynamic versions, and rich version constraints. Interviewers focus here because version sprawl is what every growing build eventually fights.
on this pageshowhide
explore
- Version Catalog TOML6 questions
- Type-Safe libs Accessors5 questions
- Declaring and Sharing Catalogs5 questions
- Platforms and BOMs5 questions
- Dynamic and Changing Versions5 questions
- Rich Version Declarations5 questions
- Dependency Version Alignment5 questions
questions
page 2 of 2Explain the priority relationship between `require`, `prefer`, and `strictly`, and how they combine within a single version block.
basics
~20 sstrictly is the hard boundary (nothing outside it is allowed), require is the acceptable range within that, and prefer is a low-priority hint used only when the range still leaves a choice. Priority: strictly defines the box, require narrows, prefer picks inside.
Catalog accessors return Provider types. What practical consequences does that laziness have, and when do you need `.get()` or `.asProvider()`?
basics
~20 sAccessors are lazy Providers, so the value is computed on demand, not at script parse time. dependencies {} accepts the Provider directly; for APIs needing a plain value you call .get(). Use .asProvider() to get a library's dependency provider from a version-bearing accessor when needed.
Why are catalog accessors like `libs` not available by default inside precompiled convention plugins or `buildSrc`, and how do you make them work there?
basics
~20 sThe libs accessor is generated for project build scripts, not for buildSrc/convention-plugin code, so it isn't on that classpath by default. You expose it by adding the catalog as a dependency in buildSrc and reading it via extensions.getByType<VersionCatalogsExtension>().named("libs").
When and how would you declare multiple named version catalogs in one build, and what are the trade-offs?
basics
~10 sCall create("name") once per catalog inside versionCatalogs; each produces its own accessor root (e.g. libs.*, testLibs.*). Use it to separate concerns, but it adds cognitive overhead, so most builds keep a single libs.
When you publish a library, how do rich version declarations affect downstream consumers, and what governance concerns does that raise?
basics
~20 sRich versions (strictly, reject, etc.) are written into Gradle Module Metadata when you publish, so consumers inherit your constraints. A strict constraint in your library can force or fail a consumer's resolution, so publish them deliberately.
How would you design an organization-wide BOM/platform strategy across many Gradle repositories, and what trade-offs would you weigh?
basics
~20 sPublish a versioned java-platform BOM as the org's single source of truth; have repos import it with platform(); release it on a cadence, prefer recommend over enforce, and provide upgrade tooling and a fallback for per-repo overrides.
showing 31–36 of 36