skip to content

How does the plugins {} block differ from the dependencies {} block, and why is it a common beginner mistake to confuse them?

level: juniorimportance: should knowfreq 55%

answer

  1. plugins = build logic/tasks
  2. dependencies = libraries for your code
  3. different positions in script
  4. same vendor can ship both
  5. import classes? dependency

basics

~10 s

plugins {} applies build logic (tasks, conventions) to the build itself; dependencies {} declares libraries your application/tests compile and run against. One shapes the build; the other shapes the program.

solid answer

~40 s

The two blocks operate at different layers. `plugins {}` applies **plugins** — units of *build logic* that contribute tasks, configurations, extensions, and conventions (e.g. `java` gives you `compileJava`/`test`; `org.springframework.boot` gives `bootJar`). `dependencies {}` declares the **libraries** your code needs, scoped to configurations like `implementation`, `api`, `testImplementation`, `runtimeOnly`. Plugins affect *how the build runs*; dependencies affect *what your program compiles and runs against*. Beginners confuse them because both reference coordinate-like strings and both can carry versions. But you'd never put `id("com.google.guava:guava")` in `plugins {}`, nor `implementation("org.springframework.boot")` to *apply* a plugin. They also sit in different positions: `plugins {}` must be first; `dependencies {}` comes later in the body and needs `repositories {}` configured for resolution.

code

kotlin · 7 lines
kotlin
plugins {
    id("org.springframework.boot") version "3.2.0"  // build logic: bootJar, bootRun
}
repositories { mavenCentral() }
dependencies {
    implementation("org.springframework.boot:spring-boot-starter-web")  // a library to import
}

go deeper

for a junior

Be able to state plugins = build logic/tasks, dependencies = libraries your code uses, and not mix them up.

for a middle

Explain configurations and that plugin vs dependency are resolved from different places and positions.

for a senior

Discuss how a single vendor ships both, and how version catalogs separate libs.plugins from libs library aliases.

for a principal

Govern both surfaces centrally (convention plugins + version catalog) so module authors don't conflate them.

## Two different layers | | `plugins {}` | `dependencies {}` | |---|---|---| | Declares | build logic (plugins) | libraries for your code | | Affects | the build (tasks, conventions) | compilation/runtime of your app | | Syntax | `id("...") version "..."` | `implementation("group:name:version")` | | Scoped by | n/a (applied to project) | configurations (implementation/api/testImplementation/...) | | Resolved from | Plugin Portal / pluginManagement | repositories {} (mavenCentral, etc.) | | Position | must be first block | later, in the body | ## What a plugin is vs what a dependency is A **plugin** is code that *configures your build* — it registers tasks (`compileJava`, `jar`, `bootRun`), adds configurations, and sets conventions. Applying `java` doesn't put any library on your application's classpath; it sets up the *machinery* to build a JVM project. A **dependency** is a library your *program* uses at compile or runtime — Guava, Jackson, JUnit. You declare it under a configuration that controls visibility and classpath: ```kotlin plugins { java // build logic: gives compileJava, test, jar... } repositories { mavenCentral() } dependencies { implementation("com.google.guava:guava:33.0.0-jre") // a library your code imports testImplementation("org.junit.jupiter:junit-jupiter:5.10.0") } ``` ## Why the confusion - Both use string coordinates and versions. - Some tools ship *both* a plugin and libraries (Spring Boot has the `org.springframework.boot` plugin AND `org.springframework.boot:spring-boot-starter-*` dependencies) — same vendor, different roles. - The Kotlin DSL `alias(libs.plugins.x)` vs `implementation(libs.x)` look similar. ## The tell - Want new **tasks / conventions / build behavior**? → `plugins {}`. - Want to **import classes** in your source code? → `dependencies {}`.

  • Spring Boot has both a plugin and starter dependencies — what's the difference in role?
    The plugin (org.springframework.boot) configures the build (bootJar/bootRun, dependency management); the starters (spring-boot-starter-*) are libraries your code compiles and runs against.
  • Can a plugin also bring libraries onto your classpath?
    Yes — some plugins add dependencies as part of their conventions, but the plugins {} block itself applies build logic; you don't list app libraries there.

saying these in an interview costs you the question

  • Putting library coordinates (group:name:version) in plugins {}.
  • Trying to apply a plugin via implementation(...) in dependencies {}.

context

resolving links…