skip to content

What do the built-in `properties` and `projects` tasks report, and how do they help inspect the build model from the CLI?

level: juniorimportance: should knowfreq 40%

answer

  1. properties = name/group/version/ext + -P overrides
  2. projects = multi-project hierarchy tree
  3. read-only model inspection
  4. scope with :path prefix
  5. confirm effective version on CI

basics

~20 s

gradle properties prints the project's properties (name, group, version, plus extra/ext and many built-ins). gradle projects prints the project hierarchy of a multi-project build as a tree with each subproject's path. Both are read-only model inspectors.

solid answer

~40 s

These two are lightweight introspection tasks. `properties` dumps the resolved set of properties visible on a project — core ones like `group`, `version`, `name`, `buildDir`/`layout.buildDirectory`, plus any `ext`/extra properties and properties injected via `-P`/`gradle.properties`. It's how you confirm what a property actually resolved to (e.g. is `version` picking up the CI override?). `projects` renders the multi-project structure: the root project and every included subproject with its `:path`, so you can see how `settings.gradle(.kts)`'s `include`/`includeBuild` shaped the build, and it even hints which tasks list a subproject's tasks. Both are scoped per project — `gradle :app:properties` reports `:app`'s view — and neither mutates anything, making them safe first-look commands when onboarding to an unfamiliar build.

code

bash · 5 lines
bash
# What did version/group actually resolve to (incl. -P/gradle.properties)?
gradle properties | grep -E '^(version|group|name):'

# Show the module hierarchy of a multi-project build
gradle projects

go deeper

for a junior

Know properties prints project props (version/group/ext) and projects prints the module tree.

for a middle

Use them to verify property overrides and module layout, scoping with :path.

for a senior

Lean on properties to debug effective config from -P/gradle.properties/init scripts and projects to reason about composite structure.

for a principal

Use them in onboarding/diagnostics conventions; ensure version/coordinate sourcing is consistent and inspectable across many modules.

## `properties` ```bash gradle properties gradle :app:properties # scoped to a subproject ``` Prints, alphabetically, the properties resolved on that project's model: - **Core build properties** — `name`, `group`, `version`, `description`, `buildDir`/`layout.buildDirectory`, `projectDir`, `status`. - **Extra (`ext`) properties** you defined and **project properties** passed with `-PkeyName=value` or set in `gradle.properties`. - Various internal/plugin-contributed properties. It's the authoritative way to answer "what did `version` actually resolve to?" — invaluable when versions come from a property override on CI or a `gradle.properties` you forgot about. (It does not print *system* properties; those are JVM-level. It prints *project* properties.) ## `projects` ```bash gradle projects ``` Renders the **project hierarchy** of a multi-project build as a tree: ``` Root project 'myapp' +--- Project ':app' \--- Project ':lib' \--- Project ':lib:core' ``` It reflects exactly what `settings.gradle(.kts)` declared via `include(':app')`, `include(':lib:core')`, etc. The output also tells you how to drill in (e.g. run `gradle :app:tasks` to see that subproject's tasks). For composite builds, included builds via `includeBuild` are separate and shown distinctly. ## Why they matter Both are **read-only** model inspectors — they configure the build and print, but mutate nothing. When you land in an unfamiliar repo, `projects` orients you to the module layout and `properties` reveals the effective coordinates/config. They pair naturally with `tasks` (what can I run?) for fast onboarding. ## Scoping Like other diagnostic tasks, prefix a project path to scope: `gradle :lib:properties` shows `:lib`'s properties, which can differ from the root's (different `version`, plugin-applied props, etc.).

  • You override a property with `-Pversion=1.2.3-ci`. How do you confirm it took effect?
    Run `gradle properties` (optionally scoped to the project) and check the `version` line — it shows the resolved value, reflecting the `-P` override or `gradle.properties`.
  • How does `projects` reflect changes in `settings.gradle.kts`?
    It renders exactly the projects declared via `include(...)`; adding/removing an `include` changes the printed tree, so it's a quick way to verify the module structure matches intent.

saying these in an interview costs you the question

  • Claiming `properties` lists JVM/system properties — it lists project properties.
  • Thinking `projects` shows tasks (it shows the project tree; use `tasks` for tasks).
  • Assuming these tasks change build state — they're purely diagnostic.

context

resolving links…