skip to content

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

level: middleimportance: must knowfreq 70%

answer

  1. GAV = groupId:artifactId:version
  2. default groups: apache.maven.plugins + codehaus.mojo
  3. maven-*-plugin vs *-maven-plugin
  4. pin version in pluginManagement
  5. enforcer requirePluginVersions

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.

solid answer

~40 s

Plugins are artifacts, so they use the same coordinate triple as dependencies: groupId:artifactId:version. For example org.apache.maven.plugins:maven-compiler-plugin:3.13.0. Two groupIds are searched by default when Maven resolves a plugin prefix: org.apache.maven.plugins (the official core plugins) and org.codehaus.mojo. That default-groupId behavior is why you can write `mvn compiler:compile` or even configure the plugin with only the artifactId in some legacy setups. Best practice today is to always pin the version explicitly (often in <pluginManagement> in a parent pom) so builds are reproducible — relying on the latest available version is non-deterministic and is flagged by the maven-enforcer-plugin's requirePluginVersions rule. The convention for official plugins is artifactId maven-*-plugin; third-party convention is *-maven-plugin.

code

xml · 5 lines
xml
<settings>
  <pluginGroups>
    <pluginGroup>com.mycompany.tools</pluginGroup>
  </pluginGroups>
</settings>

go deeper

for a junior

Knows a plugin has groupId:artifactId:version like any artifact.

for a middle

Knows the default org.apache.maven.plugins groupId and the maven-*-plugin convention, and that versions should be pinned.

for a senior

Centralizes plugin versions in pluginManagement in a parent pom and enforces them with maven-enforcer-plugin.

for a principal

Governs org-wide plugin groups/versions via a corporate parent BOM-style pom and policy enforcement in CI.

## Coordinates Every Maven artifact — including a plugin — is addressed by **coordinates**: `groupId:artifactId:version` (GAV). A plugin therefore looks like any other JAR in a repository: ``` org.apache.maven.plugins : maven-surefire-plugin : 3.2.5 ``` The difference is only in *how it is used* (it is listed under `<build><plugins>` and run as goals), not in how it is named or stored. ## The default groupId When Maven needs to turn a short *goal prefix* (like `compiler`) into a real plugin, it searches a configured list of plugin groups. By default that list is: 1. `org.apache.maven.plugins` — the official Apache-maintained core plugins. 2. `org.codehaus.mojo` — the long-standing 'MojoHaus' community plugins. Because `org.apache.maven.plugins` is searched by default, you can omit the groupId for core plugins in some contexts and Maven still finds them. You can add your own groups in `settings.xml`: ```xml <pluginGroups> <pluginGroup>com.mycompany.tools</pluginGroup> </pluginGroups> ``` ## Naming conventions - Official plugins: `maven-<name>-plugin` (e.g. `maven-jar-plugin`). - Third-party plugins: `<name>-maven-plugin` (e.g. `spring-boot-maven-plugin`). This ordering is also what lets Maven auto-derive a default prefix from the artifactId. ## Always pin the version If you omit the version, Maven historically resolved the *latest* release (or even a SNAPSHOT in older versions / from `maven-metadata.xml`), which makes builds non-reproducible — the same source could build differently on different days. Pin it, ideally centrally: ```xml <build> <pluginManagement> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>3.2.5</version> </plugin> </plugins> </pluginManagement> </build> ``` The `maven-enforcer-plugin` rule `requirePluginVersions` can fail the build if any plugin lacks an explicit version. Modern Maven (3.9+) also warns about unversioned plugins.

  • Why is omitting a plugin version dangerous?
    Maven may resolve a different (latest) version over time, breaking reproducibility; pin versions, ideally in pluginManagement.
  • Which two groupIds does Maven search by default for plugin prefixes?
    org.apache.maven.plugins and org.codehaus.mojo.
  • What is the naming convention difference between official and third-party plugins?
    Official: maven-<name>-plugin; third-party: <name>-maven-plugin.

saying these in an interview costs you the question

  • Saying plugins use a different identity scheme than dependencies — they use the same GAV coordinates.
  • Claiming you must always specify the groupId — for the default org.apache.maven.plugins group you sometimes can omit it.
  • Defending leaving plugin versions unpinned as a convenience.

context

resolving links…