skip to content

How do `reject` and `rejectAll()` work in a rich version block, and when would you use each?

level: middleimportance: should knowfreq 38%

answer

  1. reject = blacklist specific versions/ranges
  2. rejectAll() = ban every version
  3. use rejectAll on a constraint to forbid a module
  4. reject fails build if all candidates gone
  5. reject differs from exclude (fail vs prune silently)

basics

~10 s

reject lists specific versions or ranges Gradle must never resolve to — useful to blacklist a buggy or vulnerable release. rejectAll() rejects every version; on a constraint it effectively forbids the dependency from appearing.

solid answer

~40 s

Inside a `version { }` block, **`reject`** declares versions or ranges that are *never acceptable*. Resolution still chooses from the allowed range but must skip any rejected versions — so `require("[1.0,2.0[")` plus `reject("1.4", "1.4.1")` means "any 1.x except those known-bad ones". It's the standard way to blacklist a release with a regression or CVE without pinning to one exact version. **`rejectAll()`** rejects *every* version of that module. Combined with a constraint (where it doesn't add the dependency), `rejectAll()` effectively bans the module from the graph — if anything tries to pull it in, the build fails. Use `reject` for targeted exclusion of specific bad versions while staying flexible; use `rejectAll()` (via a constraint, usually with `because(...)`) when a dependency must never be present at all.

code

kotlin · 9 lines
kotlin
dependencies {
    implementation("com.fasterxml.jackson.core:jackson-databind") {
        version {
            require("[2.15, 2.17[")
            reject("2.16.0") // known regression
        }
        because("2.16.0 broke polymorphic deserialization for us")
    }
}

go deeper

for a junior

Know reject blacklists bad versions; rejectAll() bans all versions of a module.

for a middle

Explain reject-vs-exclude (fail vs silent prune) and using rejectAll() on a constraint to forbid a module.

for a senior

Discuss reject as publishable metadata and the failure mode when all candidates are rejected.

for a principal

Position rejectAll()/reject in an org policy/platform to enforce banned-library and CVE governance with visible failures.

## reject — blacklist specific versions `reject` takes one or more versions or ranges and removes them from the acceptable set. The resolver then picks the best *remaining* version. ```kotlin dependencies { implementation("org.example:lib") { version { require("[1.0, 2.0[") reject("1.4", "1.4.1", "[1.6, 1.7[") } } } ``` This says "any 1.x, but never 1.4, 1.4.1, or anything in [1.6,1.7)". Typical use: a release shipped a regression or a CVE and you want to skip it while still allowing future patches. If *every* candidate is rejected, resolution fails. ## rejectAll() — ban the module `rejectAll()` marks **all** versions unacceptable. By itself on a dependency declaration this is nonsensical (you'd reject what you're asking for). The idiomatic use is on a **constraint**, which doesn't add the dependency but constrains it *if present*: ```kotlin dependencies { constraints { implementation("commons-logging:commons-logging") { version { rejectAll() } because("we use jcl-over-slf4j instead") } } } ``` Now if any transitive path drags in `commons-logging`, the build fails, alerting you to remove or exclude it. This is a *policy* tool — it surfaces unwanted dependencies loudly instead of silently allowing them. ## reject vs exclude Note the difference from `exclude(group, module)`: `exclude` *removes* the dependency edge silently and is per-configuration/per-dependency; `rejectAll()` *fails* if the module appears, making the intent enforceable and visible. Reject participates in version selection and is publishable in Gradle Module Metadata; `exclude` is a graph-pruning instruction. ## Gotchas - Over-aggressive `reject` can make resolution unsatisfiable (all candidates rejected → failure). - `rejectAll()` as a constraint is great for governance but can break builds when a new transitive pulls the banned module — that's the point, but document it with `because(...)`.

  • What's the difference between rejectAll() and exclude(group, module)?
    exclude silently prunes the edge; rejectAll() (on a constraint) fails the build if the module shows up, making the prohibition explicit and surfacing unwanted transitives.
  • What happens if reject removes every candidate version?
    Resolution becomes unsatisfiable and the build fails because no acceptable version remains.

saying these in an interview costs you the question

  • Treating reject and exclude as identical
  • Using rejectAll() on a normal dependency declaration (you'd reject your own request)
  • Rejecting so broadly that no version can resolve

context

resolving links…