skip to content

What is <pluginGroups> in settings.xml, and how does it affect running plugin goals by prefix?

level: juniorimportance: nice to knowfreq 25%

answer

  1. pluginGroups = extra groupIds for prefix lookup
  2. defaults: org.apache.maven.plugins, org.codehaus.mojo
  3. enables mvn <prefix>:<goal>
  4. resolved via group maven-metadata.xml prefix map
  5. POM-bound plugins don't need it

basics

~10 s

<pluginGroups> lists extra groupIds Maven searches when you run a plugin by short prefix (like mvn spring-boot:run). It lets you use a plugin's prefix without typing its full groupId:artifactId.

solid answer

~40 s

`<pluginGroups>` in settings.xml extends the set of `groupId`s Maven scans when resolving a **plugin prefix** — the short name in commands like `mvn jetty:run` or `mvn spring-boot:run`. By default Maven already searches `org.apache.maven.plugins` and `org.codehaus.mojo`. If a plugin lives under another groupId (e.g. `org.springframework.boot`), adding that groupId to `<pluginGroups>` lets you invoke its goals by prefix instead of the full `groupId:artifactId:version:goal`. Maven resolves the prefix by checking each group's `maven-metadata.xml` for a matching `<prefix>`. This only affects the convenience of prefix invocation; goals invoked with fully-qualified coordinates don't need it, and plugins bound in the POM's `<build>` never need a pluginGroup entry.

code

xml · 4 lines
xml
<pluginGroups>
  <pluginGroup>org.springframework.boot</pluginGroup>
  <pluginGroup>org.mortbay.jetty</pluginGroup>
</pluginGroups>

go deeper

for a junior

Knows it lets you run a plugin by short prefix like mvn spring-boot:run.

for a middle

Knows the two default groupIds and that resolution uses maven-metadata.xml prefix mappings.

for a senior

Knows it's CLI-only convenience and distinguishes it from POM bindings and pluginRepositories.

for a principal

Standardizes common pluginGroups in org-wide settings for developer ergonomics.

## Plugin prefixes Maven lets you run a plugin goal with a short **prefix** instead of full coordinates: ```bash mvn help:effective-pom # 'help' is the prefix for maven-help-plugin mvn spring-boot:run # 'spring-boot' prefix ``` This is much friendlier than the fully-qualified form: ```bash mvn org.apache.maven.plugins:maven-help-plugin:3.4.0:effective-pom ``` ## How a prefix is resolved To turn a prefix into a plugin, Maven searches a list of `groupId`s. For each, it reads the group's `maven-metadata.xml`, which maps plugin **prefixes** to artifacts. By default the search list is: - `org.apache.maven.plugins` (the official plugins) - `org.codehaus.mojo` (the MojoHaus plugins) ## What <pluginGroups> adds If a plugin you call by prefix lives under a **different** groupId, you tell Maven to also search there: ```xml <settings> <pluginGroups> <pluginGroup>org.springframework.boot</pluginGroup> <pluginGroup>com.example.tools</pluginGroup> </pluginGroups> </settings> ``` Now `mvn spring-boot:run` resolves because Maven finds the `spring-boot` prefix under `org.springframework.boot`. ## When you do and don't need it - **Need it**: invoking a third-party plugin goal **by prefix** from the command line when its groupId isn't a default. - **Don't need it**: the plugin is bound in the POM's `<build><plugins>` (it runs by lifecycle binding), or you always type the full `groupId:artifactId:version:goal`. It's purely a CLI convenience; it doesn't change what the build does, only how concisely you can name a plugin goal.

  • Which two groupIds does Maven already search for plugin prefixes by default?
    org.apache.maven.plugins and org.codehaus.mojo. <pluginGroups> adds any others.
  • Do plugins declared in the POM <build> need a <pluginGroup> entry?
    No. pluginGroups only helps CLI prefix resolution; POM-bound plugins run via lifecycle binding and use full coordinates already.

saying these in an interview costs you the question

  • Thinking <pluginGroups> changes the build or binds plugins to phases.
  • Believing you must add every plugin's groupId there (only needed for non-default prefix invocation).
  • Confusing pluginGroups with pluginRepositories (where plugins are downloaded from).

context

resolving links…