skip to content

Plugin Model & Mojos

2 roadmaps5 questions

Plugins as bundles of goals (mojos), their coordinates, goal prefixes, and the default plugin groupId. Interviewers ask to check that you know why some goals can be typed as `help:effective-pom` and others need full coordinates.

on this pageshow

explore

questions

5

What is a Maven plugin, and how does it relate to a 'goal' (mojo)?

level: juniorimportance: must knowfreq 80%

answer

  1. plugin = JAR of goals
  2. goal = one task
  3. mojo = the Java class
  4. prefix:goal on CLI
  5. configuration block sets params

basics

~20 s

A Maven plugin is a bundle of related tasks. Each task is a 'goal', implemented by a class called a mojo. You run a goal like mvn compiler:compile, where compiler is the plugin and compile is the goal.

solid answer

~40 s

Maven itself does almost nothing on its own — all real work (compiling, testing, packaging, copying files) is done by plugins. A plugin is a JAR artifact that contains one or more goals. A goal is a single executable unit of work, implemented by a Java class called a MOJO (Maven plain Old Java Object). The naming convention is goal classes often end in 'Mojo' (e.g. CompilerMojo). You invoke a goal directly on the command line as plugin-prefix:goal, e.g. `mvn compiler:compile` or `mvn surefire:test`. Goals are also wired into lifecycle phases so that running a phase like `package` triggers the right goals automatically. Each goal can declare its own configuration parameters, which you set in the <configuration> block of the plugin in your pom.xml.

code

bash · 5 lines
bash
# Run a single goal directly (prefix:goal)
mvn compiler:compile

# Describe a plugin's goals and parameters
mvn help:describe -Dplugin=org.apache.maven.plugins:maven-compiler-plugin -Ddetail

go deeper

for a junior

Know plugin = bundle of goals, goal = single task, and that you can run prefix:goal.

for a middle

Understand mojo is the implementing class and goals are bound to phases as well as runnable directly.

for a senior

Can reason about per-execution configuration vs plugin-wide configuration and how goals expose typed parameters.

for a principal

Frames the 'engine is thin, plugins do the work' model when designing custom build tooling or org-wide plugin standards.

## The core idea Maven's engine is tiny. It knows how to read a `pom.xml`, resolve dependencies, and run a *lifecycle*. The actual build steps — compiling Java, running tests, building a JAR — are performed by **plugins**. So almost everything you think of as 'Maven doing X' is really 'a Maven plugin doing X'. ## Plugin vs. goal vs. mojo - A **plugin** is a distributable artifact (a JAR with metadata) that groups *related* capabilities. Example: the `maven-compiler-plugin`. - A **goal** is one specific task inside a plugin. The compiler plugin has two goals: `compile` (main sources) and `testCompile` (test sources). - A **mojo** (Maven plain Old Java Object) is the *Java class that implements a goal*. By convention these classes end in `Mojo` (e.g. `CompilerMojo`). 'Goal' is the user-facing name; 'mojo' is the implementation. People use the terms loosely as synonyms. ## How you run a goal Directly: `mvn <prefix>:<goal>` — e.g. `mvn compiler:compile`. Here `compiler` is the plugin's *goal prefix* (a short alias) and `compile` is the goal. Indirectly: most goals are *bound* to lifecycle phases. Running `mvn package` runs the default-lifecycle phases in order, and each phase executes whatever goals are bound to it (compiler:compile in `compile`, surefire:test in `test`, jar:jar in `package`, etc.). ## Configuration A goal exposes typed parameters. You set them in the pom: ```xml <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.13.0</version> <configuration> <release>21</release> </configuration> </plugin> </plugins> </build> ``` Here `<release>` is a parameter of the compiler mojo. The same `<configuration>` block applies to all executions of that plugin unless overridden per-execution. ## Why this matters Understanding that 'everything is a plugin goal' explains why upgrading the compiler plugin changes your Java version handling, why `mvn help:describe -Dplugin=...` lists available goals, and why build behavior is so pluggable.

  • What does 'MOJO' stand for?
    Maven plain Old Java Object — the Java class implementing a goal.
  • Does running `mvn package` invoke goals individually?
    No — it runs lifecycle phases, and each phase executes whatever goals are bound to it; you don't list goals yourself.

A plugin is like an app on your phone; each goal is one feature/button inside that app; the mojo is the code behind the button.

saying these in an interview costs you the question

  • Saying Maven compiles/tests/packages 'by itself' — it delegates all of that to plugins.
  • Claiming a plugin can only have one goal — plugins typically bundle several related goals.

context

resolving links…

open as a page

How do you uniquely identify a Maven plugin, and what is special about the org.apache.maven.plugins groupId?

level: middleimportance: must knowfreq 70%

basics

~10 s

A plugin is identified by coordinates groupId:artifactId:version, just like a dependency. The groupId org.apache.maven.plugins is the default Maven assumes for core plugins, so you can sometimes omit it.

open as a page

How do you configure a plugin and bind specific goals to run, including multiple separate runs of the same plugin?

level: middleimportance: should knowfreq 55%

basics

~10 s

Set parameters in the plugin's <configuration> block. To run goals at build time, add <executions>: each <execution> lists <goals>, an optional <phase>, an <id>, and its own <configuration>. Multiple executions = multiple runs.

open as a page

How does Maven resolve a short goal prefix like 'help' or 'spring-boot' to an actual plugin artifact?

level: seniorimportance: should knowfreq 45%

basics

~20 s

Maven looks up the prefix in maven-metadata.xml files stored under each configured plugin group in the repositories. That metadata maps a prefix (e.g. help) to a plugin artifactId, so prefix:goal can be resolved to a real plugin.

open as a page

What does it take to write your own Maven plugin, and what are the key annotations and packaging involved?

level: seniorimportance: nice to knowfreq 25%

basics

~10 s

Create a project with <packaging>maven-plugin</packaging>, depend on maven-plugin-api, and write a class extending AbstractMojo. Annotate it with @Mojo(name="...") and @Parameter fields, implement execute(), and the maven-plugin-plugin generates the descriptor.

open as a page