Version not locked for default bindings plugins {}, you shou

Error message

Version not locked for default bindings plugins {}, you should define versions in pluginManagement section of your pom.xml or parent

What it means

BuilderCommon inspects the execution plan for plugins whose <version> comes from the default lifecycle bindings model (DefaultLifecycleRegistry.DEFAULT_LIFECYCLE_MODELID) rather than from the user's POM. Such versions float with the Maven version and are not 'locked'; Maven warns that you should declare them in pluginManagement. Only core groupId org.apache.maven.plugins bindings are considered, hence the artifactId-only list.

Source

Thrown at impl/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/BuilderCommon.java:157

                }
                logger.warn(MultilineMessageHelper.separatorLine());
            }
        }

        final String defaulModelId = DefaultLifecycleRegistry.DEFAULT_LIFECYCLE_MODELID;

        List<String> unversionedPlugins = executionPlan.getMojoExecutions().stream()
                .map(MojoExecution::getPlugin)
                .filter(p -> p.getLocation("version") != null
                        && p.getLocation("version").getSource() != null
                        && defaulModelId.equals(
                                p.getLocation("version").getSource().getModelId()))
                .distinct()
                .map(Plugin::getArtifactId) // managed by us, groupId is always o.a.m.plugins
                .toList();

        if (!unversionedPlugins.isEmpty()) {
            logger.warn("Version not locked for default bindings plugins " + unversionedPlugins
                    + ", you should define versions in pluginManagement section of your " + "pom.xml or parent");
        }

        return executionPlan;
    }

    public void handleBuildError(
            final ReactorContext buildContext,
            final MavenSession rootSession,
            final MavenSession currentSession,
            final MavenProject mavenProject,
            Throwable t,
            final Instant buildStartTime) {
        // record the error and mark the project as failed
        Instant buildEndTime = MonotonicClock.now();
        buildContext.getResult().addException(t);
        buildContext
                .getResult()

View on GitHub (pinned to e4093d4e12)

Solutions

Copy the listed artifactIds into <build><pluginManagement><plugins> with explicit versions (run mvn help:effective-pom to see current defaults).
Adopt the oldest-allowed / version-locked parent approach (e.g. a corporate parent POM that pins all core plugins).
Run 'mvn versions:display-plugin-updates' to pick current versions, then pin them.
Re-run the build to confirm the warning disappears and builds are reproducible across Maven versions.

Example fix

<!-- before: implicit versions from default bindings -->
<artifactId>maven-jar-plugin</artifactId><!-- no version anywhere -->

<!-- after: lock versions in pluginManagement -->
<build>
  <pluginManagement>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jar-plugin</artifactId>
        <version>3.4.2</version>
      </plugin>
    </plugins>
  </pluginManagement>
</build>

Defensive patterns

Strategy: validation

Validate before calling

# guard: detect floating default-binding versions before they drift
mvn -q help:effective-pom -Doutput=/tmp/eff.xml
xmllint --xpath '//*[local-name()="plugin" and not(*[local-name()="version"])]/*[local-name()="artifactId"]/text()' /tmp/eff.xml

Prevention

Pin every core plugin (compiler, surefire, jar, install, deploy, resources) in pluginManagement of a shared parent.
Add maven-enforcer requirePluginVersions rule so POMs cannot rely on implicit versions.
Re-run builds after Maven upgrades with locked versions to prove reproducibility.

When it happens

Trigger: A project (usually generated by an older archetype or hand-written) relies on implicit default bindings — e.g. a jar project with no explicit maven-surefire-plugin/maven-compiler-plugin versions — so p.getLocation("version").getSource().getModelId() equals the default-bindings model id.

Common situations: Reproducibility audits: the same POM builds differently on Maven 3.8 vs 3.9 vs 4 because surefire/jar/install versions changed with the Maven distribution; CI 'works on my machine' drift after a Maven upgrade; builds behind an air-gapped repo that lacks the newly-defaulted plugin version.

Related errors

AI-assisted analysis of apache/maven@e4093d4e12 (2026-08-21). Data as JSON: /api/errors/f0b3a270d279f85e. Report an issue: GitHub.