Plugins
Applying plugins through the plugins {} block, managing their versions and resolution, the core plugin families, and where community plugins come from. Interviewers ask because plugins supply nearly all of a real build's behavior.
on this pageshowhide
explore
- Applying Plugins31 questions
- plugins {} DSL Block6 questions
- Plugin Version Resolution5 questions
- apply false in Multi-Project Builds5 questions
- Plugin ID vs Marker Artifact5 questions
- Legacy apply() and apply(from=)5 questions
- Reacting to Applied Plugins5 questions
- Plugin Management21 questions
- pluginManagement {} in settings5 questions
- Resolution Strategy and Version Pinning5 questions
- Gradle Plugin Portal5 questions
- Settings Plugins6 questions
- Core Plugin Families20 questions
- JVM Language Plugins5 questions
- Base and Lifecycle-Base Plugins5 questions
- Reporting Plugins5 questions
- Source Sets5 questions
questions
72 · 3 sectionsIn a multi-project Gradle build, what does declaring a plugin with `apply false` in the root build script do, and why would you do it?
basics
~10 sapply false adds the plugin to the build's classpath and resolves its version, but does NOT apply (activate) it to the root project. Subprojects can then apply it by id with no version.
What is the legacy apply(plugin = "...") syntax in Gradle, and how does it differ from the modern plugins {} DSL?
basics
~20 sapply(plugin = "...") is the old imperative way to apply a plugin by ID anywhere in the build script. The modern plugins {} DSL is a declarative block at the top that Gradle understands ahead of time.
What is the plugins {} block in a Gradle build script, and how do you apply a core plugin and a community plugin with it?
basics
~10 sThe plugins {} block is the declarative way to apply Gradle plugins. Use id("...") for a plugin, adding version "..." for community plugins. Core plugins like java need no version.
How do you declare a plugin and its version in the plugins {} block, and where does Gradle resolve that plugin from?
basics
~10 sUse id("com.example.foo") version "1.2.3" inside plugins {}. Gradle resolves the plugin from the Gradle Plugin Portal (or repositories declared in settings' pluginManagement) by looking up its marker artifact.
A teammate adds `id('org.jetbrains.kotlin.jvm') version '1.9.24'` (with the version) to two different subprojects' build scripts and the build fails. Why, and how does the `apply false` pattern fix it?
basics
~20 sRequesting the same plugin version in two projects sharing a classpath conflicts. You fix it by requesting the version once at the root with apply false, then applying by id (no version) in each subproject.
What is the pluginManagement {} block, and where must it appear in a Gradle build?
basics
~10 spluginManagement {} is a block in settings.gradle.kts that configures where Gradle resolves plugins from (repositories) and how. It must be the first block in the settings file, before anything else.
What is the Gradle Plugin Portal, and how does Gradle use it by default to resolve plugins applied via the plugins {} block?
basics
~10 sThe Gradle Plugin Portal (plugins.gradle.org) is the public registry of community Gradle plugins. By default Gradle searches it via gradlePluginPortal() to resolve plugins declared by id in the plugins {} block.
What is a Settings plugin in Gradle, and where do you apply one?
basics
~10 sA Settings plugin implements Plugin<Settings> and is applied in the plugins {} block of settings.gradle.kts. It runs during the settings phase, before any project is configured.
Inside pluginManagement, how do you configure plugin repositories, and what is the default if you don't?
basics
~10 sAdd a repositories {} block inside pluginManagement {} and call helpers like gradlePluginPortal() and mavenCentral(). If you declare none, Gradle defaults to the Gradle Plugin Portal only.
How do you configure Gradle to resolve internal/company plugins alongside the public Gradle Plugin Portal?
basics
~10 sAdd your internal Maven repository to pluginManagement.repositories in settings, and re-add gradlePluginPortal() so both public and internal plugins resolve. Order/strategy decides precedence.
What lifecycle tasks does the Gradle 'base' plugin contribute, and what does each one mean?
basics
~10 sThe base plugin adds 'assemble' (build all artifacts), 'check' (run all verification like tests), 'build' (assemble + check together), and 'clean' (delete the build directory).
What does applying the core `java` plugin give you in a Gradle build?
basics
~10 sThe java plugin adds the main and test source sets, compile tasks (compileJava, compileTestJava), processResources, the jar task, and the standard build/check/assemble lifecycle wiring.
What does the `project-report` plugin add to a Gradle build, and which report tasks does it contribute?
basics
~10 sApplying project-report adds tasks that generate diagnostic reports: dependencyReport, taskReport, propertyReport, and the aggregate projectReport task, plus an HTML dependency report.
What is a SourceSet in Gradle's Java plugin, and what two source sets does the plugin create by default?
basics
~10 sA SourceSet is a named group of source files compiled together. The java plugin creates two by default: main (production code) and test (test code that depends on main's output).
You wrote a custom task that packages a distribution. How do you make `gradle build` run it, and where should it hook?
basics
~10 sMake assemble depend on your packaging task: tasks.named("assemble") { dependsOn(myTask) }. Since build depends on assemble, gradle build will then run it.