What does the Gradle `init` task do, and how do you use it to scaffold a new project?
answer
- build-init plugin task
- generates settings + build scripts
- creates the Gradle wrapper
- interactive prompts or flags
- run with system gradle once
basics
~20 sgradle init is a built-in task from the build-init plugin that scaffolds a new Gradle project: it generates build/settings scripts, a sample source layout, and the Gradle wrapper, prompting you (or via flags) for project type, DSL, and test framework.
solid answer
~40 s`gradle init` is the entry-point task of the bundled `build-init` plugin. Run from an empty (or existing) directory, it bootstraps a new build: it writes `settings.gradle(.kts)`, one or more `build.gradle(.kts)` scripts, a skeleton `src/main` + `src/test` layout, a `.gitignore`, and—critically—the **Gradle wrapper** (`gradlew`, `gradlew.bat`, `gradle/wrapper/*`) so collaborators don't need Gradle pre-installed. Interactively it asks for the project type (e.g. `java-application`, `kotlin-library`), the build DSL (Kotlin or Groovy), the test framework, and a project name. All of those can be supplied non-interactively as flags (`--type`, `--dsl`, `--test-framework`) for CI or scripting. Because you usually run it before Gradle is installed locally, you invoke the system `gradle` once, then switch to `./gradlew` thereafter.
code
bash · 12 lines# Interactive scaffold
gradle init
# Fully non-interactive (CI-friendly)
gradle init \
--type java-application \
--dsl kotlin \
--test-framework junit-jupiter \
--project-name myapp
# After init, always use the wrapper
./gradlew buildgo deeper
Know that gradle init scaffolds a new project and creates the wrapper; be able to run it interactively.
Explain the flags (--type, --dsl, --test-framework) and the full set of generated artifacts including settings, build scripts, and version catalog.
Discuss running it non-interactively in tooling, migrating from Maven, and why the wrapper guarantees reproducible builds.
Frame init as a standardization lever—seeding org-wide conventions (DSL choice, version catalogs, test framework) consistently across new repos.
## What `init` is `init` is a task contributed by the **`build-init` plugin**, one of the plugins Gradle bundles into its distribution. You don't apply it in a build script—it's available from a system `gradle` install (or even an empty directory) so it can create a build *from scratch*. ## What it generates For a typical application type, `gradle init` produces: - `settings.gradle.kts` (or `.groovy`) declaring `rootProject.name` and included subprojects. - `build.gradle.kts` for each generated project/subproject with plugins, dependencies, and a configured test framework. - A source skeleton: `app/src/main/...` and `app/src/test/...` with a sample class and test. - The **Gradle wrapper**: `gradlew`, `gradlew.bat`, `gradle/wrapper/gradle-wrapper.jar`, and `gradle/wrapper/gradle-wrapper.properties`. This pins the Gradle version so everyone builds reproducibly. - A `.gitignore` and (for newer types) a `gradle/libs.versions.toml` version catalog. ## Interactive vs non-interactive Run with no arguments, `init` *interactively prompts* for: type, implementation language, build DSL, test framework, project name, and source package. Each prompt can be pre-answered with a flag so the task is fully scriptable: ```bash gradle init --type java-application --dsl kotlin --test-framework junit-jupiter --project-name myapp ``` ## Why the wrapper matters Because `init` is often the *first* Gradle command in a project's life, generating the wrapper means the next person who clones the repo runs `./gradlew build` with the exact pinned Gradle version—no manual install, no version drift. After `init`, you stop using the system `gradle` and use `./gradlew`. ## Detecting existing projects If you run `init` in a directory that already contains a Maven `pom.xml`, the plugin can migrate it (`--type pom`). In an empty directory with no flags it asks what to build.
- Why does `init` generate the Gradle wrapper?So the project pins its Gradle version and teammates/CI can build with `./gradlew` without any local Gradle install, guaranteeing a reproducible version.
- Do you apply the build-init plugin in your build script?No. It's bundled into the Gradle distribution and exposed automatically by a system `gradle` install (or from an empty directory), so its `init` task is always available.
saying these in an interview costs you the question
- Claiming you must add `build-init` to the plugins block—it's bundled, not applied.
- Saying `init` only writes a build script and forgetting it also generates the wrapper and source skeleton.