Resolution and Conflicts

It pins Guava to exactly that version for the whole configuration, overriding whatever version conflict resolution would otherwise pick — even if another dependency wants a higher one.

Dependency locking pins the exact versions a configuration resolves to, saving them in a lockfile. With dynamic versions or version ranges, builds can drift over time; locking makes resolution reproducible across machines and over time.

Dependency substitution lets you swap one dependency for another during resolution — for example, replacing a published external module with a local project so you build and test against your own source instead of a release.

A capability is a label (group:name:version) saying 'I provide this feature'. By default a module provides one capability matching its GAV. Two modules offering the same capability conflict, even if they are different modules — like log4j and log4j-over-slf4j both providing logging.

Run ./gradlew dependencyInsight --configuration <cfg> --dependency <module>. It prints the selected version, every path that requested the module, and the reason for selection — e.g. 'by conflict resolution'.

Add a constraint with a strict version: constraints { implementation('g:a') { version { strictly('1.2.3') } } }. Unlike force, it's a first-class version requirement that participates in resolution and fails loudly if something genuinely needs another version.

Add a dependencyLocking { lockAllConfigurations() } block, then run a resolving task with --write-locks (e.g. ./gradlew dependencies --write-locks). Gradle writes the resolved versions to gradle.lockfile, which you commit.

Guava absorbed all of google-collections' classes. If both end up on the classpath you get duplicate classes and NoSuchMethodError. Declaring google-collections replacedBy guava makes Gradle evict the old one, leaving only guava.

Module replacement tells Gradle that one module is a drop-in successor of another (e.g. google-collections was replaced by guava), so during conflict resolution Gradle treats them as the same logical component and keeps only the replacement.

ResolutionResult gives the resolved dependency graph as components and dependencies, including versions chosen and reasons. Listing files gives only the resolved artifacts on disk, with no graph structure or selection metadata.

useVersion changes only the version of the requested module, keeping its group and name. useTarget replaces the whole coordinate (group:name:version), letting you redirect one module to an entirely different one.

eachDependency registers a rule that Gradle invokes for every dependency while resolving a configuration. The rule receives DependencyResolveDetails and can rewrite the requested version or coordinates before the dependency graph is built.

includeBuild wires a separate Gradle build into yours. Gradle automatically substitutes any external dependency whose coordinates match a project published by the included build, so you transparently build against that build's source.

Use resolutionStrategy.capabilitiesResolution.withCapability('group:name') { select(...) } inside a configuration. The closure receives the conflicting candidates and you call select() to pick one, or selectHighestVersion() to take the newest.

./gradlew dependencies prints the full resolved dependency tree per configuration. A line like 'lib:1.0 -> 2.0' shows that 1.0 was requested but the build resolved 2.0 — that request lost the conflict.

Add configurations.all { resolutionStrategy.eachDependency { if it's the vulnerable module, useVersion("safe") } }. The rule fires for every transitive, so every path to that module resolves to the safe version.

Two variants in your graph declare the same capability, so they're mutually exclusive and Gradle refuses to put both on the classpath. You must pick one — via a capabilitiesResolution rule, or by removing/substituting one of the modules.

It switches a configuration's resolution strategy so that any version conflict between transitive dependencies makes the build fail instead of silently picking the highest version, forcing the team to resolve it explicitly.

require is the minimum acceptable (default); higher is fine. prefer is a soft tie-breaker used only when nothing else decides. strictly is a hard requirement that can downgrade and fail. reject blacklists versions that otherwise qualify.

--write-locks re-resolves freely and rewrites all lock entries for the configurations it resolves. --update-locks group:module re-resolves but only lets the named modules change, keeping every other locked version pinned.

Declare it in the dependencies block: dependencies { modules { module('g:old') { replacedBy('g:new', 'reason') } } }. To apply across subprojects, put it in a convention plugin or a shared script applied to each project.

An artifactView lazily produces a filtered/transformed set of resolved artifacts from a configuration. lenient = true makes it ignore resolution and artifact failures instead of throwing, returning whatever resolved successfully.

Yes. substitute(module("g:n")).using(module("g:n:1.5")) changes the version; substitute(module("g:n")).using(module("g2:n2:1.0")) swaps to a different module. The substituted node then participates in normal conflict resolution.

Substitution redirects a dependency to a different one (including a local project) during resolution. Replacement signals two modules are the same library under different coordinates. Exclude removes a transitive. Force/pin only chooses a version. Pick by intent.

Add a component metadata rule that attaches the same capability to both modules: components.withModule(...) { allVariants { withCapabilities { addCapability(group, name, version) } } }. Once both share a capability, Gradle treats them as conflicting.

Each resolvable configuration (compileClasspath, runtimeClasspath, etc.) is resolved independently, so highest-version-wins runs separately per configuration. Different requested-version sets can therefore yield different winners.

Maven uses 'nearest definition wins' — the version closest to the root of the tree. Gradle uses 'highest version wins' regardless of depth. So migrating builds can silently pick different versions.

Run gradle dependencyInsight --dependency lib to see the selected version and reason. A forced downgrade can pull in an API too old for callers, causing NoSuchMethodError; the fix is usually to align upward or remove the override, not pin lower.

gradle.lockfile lists group:artifact:version=configurations lines plus an empty= line. On a normal build, if resolution would differ from these pins, Gradle fails with a lock-state mismatch error telling you what changed.