skip to content

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…