skip to content

Core Build Plugins

2 roadmaps6 questions

The clean, resources, jar, install, deploy, and site plugins that implement the default lifecycle for each packaging type. Interviewers use this to confirm you can name what runs when nobody has configured anything.

on this pageshow

explore

questions

6

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…

open as a page

How does the <packaging> value determine which plugin goals are bound to lifecycle phases by default?

level: middleimportance: must knowfreq 60%

basics

~10 s

The packaging type selects a default set of goal-to-phase bindings. For example jar binds jar:jar at package, while pom binds almost nothing and war binds war:war instead.

open as a page

How does maven-resources-plugin work, and what does resource filtering do?

level: middleimportance: should knowfreq 45%

basics

~10 s

maven-resources-plugin copies files from src/main/resources into target/classes. With filtering enabled, it replaces ${...} placeholders in those files with property values during the copy.

open as a page

Walk through what maven-deploy-plugin does at the deploy phase, and how SNAPSHOT versions are handled differently from releases.

level: seniorimportance: should knowfreq 40%

basics

~10 s

deploy uploads the artifact and POM to a remote repository. SNAPSHOT versions go to the snapshots repo and can be re-deployed (overwritten with timestamps); release versions go to the releases repo and are immutable.

open as a page

Why should core plugin versions be pinned and managed centrally, and how do you do it across a multi-module build?

level: principalimportance: should knowfreq 35%

basics

~10 s

If you don't pin core plugin versions, Maven picks defaults that can change between Maven releases, making builds non-reproducible. Pin them in <pluginManagement> in a parent POM so every module uses the same versions.

open as a page

What is the maven-site-plugin for, and when would you still use it today?

level: juniorimportance: nice to knowfreq 15%

basics

~10 s

maven-site-plugin generates a static HTML website for a project, including reports like javadoc, test results, and dependency info. It runs on the separate site lifecycle via mvn site.

open as a page