skip to content

What does the `buildEnvironment` task report, and why is it distinct from `dependencies`?

level: middleimportance: should knowfreq 45%

answer

  1. buildscript classpath / plugin deps
  2. separate from app's runtimeClasspath
  3. debug plugin version conflicts
  4. same annotations as dependencies
  5. build tooling, not app code

basics

~20 s

buildEnvironment prints the dependency tree of the buildscript classpath — the plugins and libraries used to configure the build itself, from buildscript { dependencies { classpath … } }. dependencies covers your application's configurations instead.

solid answer

~40 s

There are two completely separate dependency worlds in a Gradle build: the dependencies your *project* compiles/runs against (resolved in normal configurations like `runtimeClasspath`) and the dependencies that the *build itself* uses to run — plugins, their transitive libraries, and anything on the `buildscript` classpath. `dependencies` reports the former; `buildEnvironment` reports the latter. Run `gradle buildEnvironment` to see the resolved tree of the `classpath` configuration of the buildscript, with the same conflict/omission annotations. This is the tool you use when a *plugin* misbehaves — e.g. two plugins pull conflicting versions of a shared library, or you need to know which version of a transitively-loaded library a plugin actually runs with. It does not show your app's deps at all, which is exactly why it's a separate task.

code

bash · 4 lines
bash
# What does the build itself (plugins + their transitives) run with?
gradle buildEnvironment

# Example: spot two plugins fighting over asm versions in the output tree.

go deeper

for a junior

Know buildEnvironment shows plugin/buildscript dependencies, separate from your app's deps.

for a middle

Use it to diagnose plugin version conflicts and read the buildscript tree.

for a senior

Reason about the two-classpath model and resolve plugin clashes (constraints in buildSrc/settings, plugin version alignment).

for a principal

Govern plugin versions org-wide (version catalogs/convention plugins) so the build classpath stays consistent and auditable.

## Two dependency worlds A Gradle build has a layered classpath model: 1. **Project (production) dependencies** — declared in `dependencies { }`, resolved into configurations like `compileClasspath`/`runtimeClasspath`. These are what your code compiles and runs against. 2. **Buildscript (build-tooling) dependencies** — the plugins and libraries Gradle loads to *execute the build*. These come from applied plugins and from the legacy `buildscript { dependencies { classpath '…' } }` block. These never mix. A version of a library on your app classpath has nothing to do with the version a *plugin* uses internally. ## What `buildEnvironment` shows ```bash gradle buildEnvironment ``` It prints the resolved tree of the buildscript `classpath` configuration — every plugin and its transitive dependencies, with the familiar annotations (`->` conflict, `(*)` omitted, `(c)` constraint). Effectively it's `dependencies` but pointed at the build's own tooling classpath. ## When you reach for it - A plugin throws `NoSuchMethodError` internally — find which transitive version it loaded. - Two plugins clash over a shared library (e.g. both bundle different `kotlin-stdlib` or `asm` versions). - You added a plugin and want to confirm what it dragged onto the build classpath. - Diagnosing slow configuration caused by heavy plugin dependencies. ## Why it's a separate task Keeping it distinct from `dependencies` makes the boundary explicit: build-time tooling vs. runtime code. Mixing them would be confusing and could imply they share resolution, which they don't.

  • If a Gradle plugin fails internally with a version-related error, which report do you run and why?
    `buildEnvironment`, because the failing classes live on the buildscript classpath, not your app's configurations; it shows the plugin's resolved transitive versions and any conflicts.
  • Can `buildEnvironment` show your application's `runtimeClasspath` dependencies?
    No — it only covers the buildscript/plugin classpath. Use `dependencies --configuration runtimeClasspath` for app dependencies.

dependencies shows the ingredients in the dish; buildEnvironment shows the tools in the kitchen that cook it.

saying these in an interview costs you the question

  • Conflating the buildscript classpath with the application classpath.
  • Believing plugin library versions affect your app's runtime versions (they don't).
  • Reaching for `dependencies` to debug a plugin's internal version conflict.

context

resolving links…