skip to content

What are Maven's core build plugins, and what is each one responsible for during a build?

level: juniorimportance: must knowfreq 70%

answer

  1. clean/resources/jar/install/deploy/site
  2. install=local .m2, deploy=remote
  3. resources can filter ${...}
  4. goals bound to phases via Super POM
  5. war/ear swap out jar plugin

basics

~20 s

Core build plugins handle the standard build steps: clean removes target/, resources copies non-code files, jar packages a JAR, install copies the artifact to the local repository, and deploy uploads it to a remote repository.

solid answer

~30 s

Maven's build lifecycle is implemented by a small set of core plugins, each owning one job. maven-clean-plugin deletes the `target/` output directory. maven-resources-plugin copies `src/main/resources` (and test resources) into `target/classes`, optionally filtering placeholders. maven-jar-plugin (or war/ear) packages compiled classes plus resources into the artifact. maven-install-plugin copies that artifact plus its POM into your `~/.m2` local repository so other local builds can resolve it. maven-deploy-plugin uploads it to a remote repository (Nexus/Artifactory) defined in `distributionManagement`. maven-site-plugin generates project documentation. These are bound to lifecycle phases automatically, so you rarely configure them by hand for a normal JAR project.

code

bash · 4 lines
bash
mvn clean          # maven-clean-plugin: rm -rf target/
mvn package        # resources + compile + test + jar
mvn install        # also copies artifact to ~/.m2
mvn deploy         # also uploads to remote repo (needs distributionManagement)

go deeper

for a junior

Name the plugins and one-line each: clean, resources, jar, install, deploy, site.

for a middle

Explain which phase each binds to and that install is local while deploy is remote.

for a senior

Discuss when to override (executable jar manifest, resource filtering), and packaging-driven plugin swaps (war/ear).

for a principal

Govern plugin versions centrally via pluginManagement/parent POM so the whole org has reproducible builds, and reason about supply-chain pinning.

## What "core build plugins" means Maven does almost nothing by itself. The *lifecycle* (the ordered list of phases like `compile`, `test`, `package`, `install`, `deploy`) is just a sequence of named steps. The actual work is done by **plugins** whose **goals** are bound to those phases. A handful of plugins ship and bind automatically for every project — these are the core build plugins. ## The plugins and their jobs - **maven-clean-plugin** — goal `clean`. Deletes the build output directory (`target/`). Bound to the `clean` phase of the separate *clean* lifecycle. Running `mvn clean` gives you a fresh start. - **maven-resources-plugin** — goals `resources` and `testResources`. Copies non-source files (`src/main/resources` → `target/classes`, `src/test/resources` → `target/test-classes`). Can do **filtering**: replacing `${...}` placeholders with property values when `<filtering>true</filtering>` is set. - **maven-jar-plugin** — goal `jar`. Takes everything in `target/classes` and zips it into `target/<artifactId>-<version>.jar`, writing the `MANIFEST.MF`. (For `war` packaging it is maven-war-plugin; for `ear`, maven-ear-plugin.) - **maven-install-plugin** — goal `install`. Copies the built artifact and its POM into the **local repository** (`~/.m2/repository`) so other projects on the same machine can depend on it. - **maven-deploy-plugin** — goal `deploy`. Uploads the artifact + POM to a **remote repository** declared in `<distributionManagement>` (releases vs snapshots). This is the final, sharing step in CI. - **maven-site-plugin** — goals `site`/`site:deploy`. Generates an HTML project site (reports, javadoc, etc.). Less used today but still a core plugin. ## How they get wired in For `<packaging>jar</packaging>` Maven binds default goals to phases (process-resources→resources, package→jar, install→install, deploy→deploy). You usually do not declare these plugins at all — they are inherited from the **Super POM**. You only add `<plugin>` config to override versions or behavior (e.g. an executable JAR manifest). ```xml <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <configuration> <archive> <manifest> <mainClass>com.example.App</mainClass> </manifest> </archive> </configuration> </plugin> </plugins> </build> ``` ## Key distinctions - **install vs deploy**: install = local machine only; deploy = shared remote repo. Confusing these is a classic mistake. - compiler and surefire/failsafe are *also* core but are covered separately — don't list them as your only answer here.

  • What is the difference between mvn install and mvn deploy?
    install copies the artifact into the local ~/.m2 repository for use by other local builds; deploy uploads it to a remote repository (defined in distributionManagement) so the whole team/CI can consume it.
  • If you change packaging from jar to war, which core plugin changes?
    maven-jar-plugin is replaced by maven-war-plugin for the package step; the others (clean, resources, install, deploy) stay the same.

Think of a bakery line: clean wipes the counter, resources lays out ingredients, jar boxes the cake, install puts it in your home fridge, deploy ships it to the store.

saying these in an interview costs you the question

  • Saying install uploads to a remote/shared repository — that is deploy.
  • Claiming you must explicitly declare these plugins in every pom — they are inherited from the Super POM.
  • Listing only compiler/surefire, which are covered separately.

context

resolving links…