'{}' uses '{}' as extension which is not possible within the

Error message

'{}' uses '{}' as extension which is not possible within the same reactor build. This plugin was pulled from the local repository!

What it means

MNG-1911/MNG-5572: a plugin declared with <extensions>true</extensions> must extend Maven's core before the reactor builds, but if that plugin is itself a reactor module it cannot be used from the reactor. Maven takes it from the local repository instead and warns; on a machine where the plugin was never installed, the build later fails with a resolution error for that plugin.

Source

Thrown at impl/maven-core/src/main/java/org/apache/maven/graph/DefaultGraphBuilder.java:389

            throws MavenExecutionException {
        Map<String, MavenProject> projectsMap = new HashMap<>();

        List<MavenProject> projectsInRequestScope = getProjectsInRequestScope(request, projects);
        for (MavenProject p : projectsInRequestScope) {
            String projectKey = ArtifactUtils.key(p.getGroupId(), p.getArtifactId(), p.getVersion());

            projectsMap.put(projectKey, p);
        }

        for (MavenProject project : projects) {
            // MNG-1911 / MNG-5572: Building plugins with extensions cannot be part of reactor
            for (Plugin plugin : project.getBuildPlugins()) {
                if (plugin.isExtensions()) {
                    String pluginKey =
                            ArtifactUtils.key(plugin.getGroupId(), plugin.getArtifactId(), plugin.getVersion());

                    if (projectsMap.containsKey(pluginKey)) {
                        LOGGER.warn(
                                "'{}' uses '{}' as extension which is not possible within the same reactor build. "
                                        + "This plugin was pulled from the local repository!",
                                project.getName(),
                                plugin.getKey());
                    }
                }
            }
        }
    }

    private void processPackagingAttribute(List<MavenProject> projects, MavenExecutionRequest request)
            throws MavenExecutionException {
        List<MavenProject> projectsInRequestScope = getProjectsInRequestScope(request, projects);
        for (MavenProject p : projectsInRequestScope) {
            if ("bom".equals(p.getPackaging())) {
                LOGGER.info(
                        "The packaging attribute of the '{}' project is configured as 'bom' and changed to 'pom'",
                        p.getName());

View on GitHub (pinned to e4093d4e12)

Solutions

Two-phase build: first mvn install -pl <extension-module> (optionally -am), then build the full reactor - this is the standard bootstrap procedure
If you do not actually need core extension behavior, remove <extensions>true</extensions> from the plugin declaration
Pin the plugin's <version> so the local-repository fallback is deterministic, and document the pre-install step for all consumers

Example fix

<!-- before: extension plugin built in same reactor, resolved from local repo (stale or missing) -->
<plugin>
  <groupId>com.acme</groupId>
  <artifactId>acme-packaging</artifactId>
  <version>1.0</version>
  <extensions>true</extensions>
</plugin>
<!-- after (if extension behavior not needed): drop the flag; otherwise pre-install the module -->
<plugin>
  <groupId>com.acme</groupId>
  <artifactId>acme-packaging</artifactId>
  <version>1.0</version>
</plugin>
<!-- bootstrap once: mvn install -pl acme-packaging && mvn install -->

Defensive patterns

Strategy: validation

Validate before calling

# bootstrap check: verify the extension plugin is in the local repo before the reactor build
G= com.acme; A=acme-packaging; V=1.0
[ -d "$HOME/.m2/repository/$G/$(echo $A | tr . /)/$V" ] || mvn -q install -pl acme-packaging
mvn clean install

Prevention

Keep extension/core-extension plugins OUT of the reactor that consumes them - build them in a separate reactor or phase
Document and script the two-phase bootstrap (install extension first, then full build)
Pin the extension plugin's version so the local-repo fallback is deterministic

When it happens

Trigger: A multi-module build where the module producing a custom extension/plugin is listed in <modules> and that same plugin (or a sibling using it) declares it with <extensions>true</extensions> in <build><plugins>; running on a clean local repository (~/.m2 has no prior install of the plugin).

Common situations: Bootstrapping a repository that contains its own custom packaging or core extension; dogfooding an in-house extension inside the same reactor; fresh CI containers with an empty local repo.

Related errors

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