apache/maven · warning

{} mojo is already being executed on the project {}:{} This

Error message

{} mojo is already being executed on the project {}:{} This mojo execution will be blocked until the mojo is done.

What it means

The same MojoExecutor lock scheme also serializes access per project: getProjectLock(session) returns a per-project lock, and when tryLock() fails because another thread is already running a mojo on the same G:A, this warning is logged and the thread blocks until that mojo completes. It indicates two mojos were scheduled concurrently for one module — usually an aggregator-adjacent overlap or forked executions targeting the same project.

Source

Thrown at impl/maven-core/src/main/java/org/apache/maven/lifecycle/internal/MojoExecutor.java:261

                MojoDescriptor ownerMojo = owner != null ? mojos.get(owner) : null;
                String str = ownerMojo != null ? " The " + ownerMojo.getId() : "An";
                String msg = str + " aggregator mojo is already being executed "
                        + "in this parallel build, those kind of mojos require exclusive access to "
                        + "reactor to prevent race conditions. This mojo execution will be blocked "
                        + "until the aggregator mojo is done.";
                warn(msg);
                acquiredAggregatorLock.lock();
            }
            if (!acquiredProjectLock.tryLock()) {
                Thread owner = acquiredProjectLock.getOwner();
                MojoDescriptor ownerMojo = owner != null ? mojos.get(owner) : null;
                String str = ownerMojo != null ? " The " + ownerMojo.getId() : "A";
                String msg = str + " mojo is already being executed "
                        + "on the project " + session.getCurrentProject().getGroupId()
                        + ":" + session.getCurrentProject().getArtifactId() + ". "
                        + "This mojo execution will be blocked "
                        + "until the mojo is done.";
                warn(msg);
                acquiredProjectLock.lock();
            }
        }

        @Override
        public void close() {
            // release the lock in the reverse order of the acquisition
            acquiredProjectLock.unlock();
            acquiredAggregatorLock.unlock();
            mojos.remove(Thread.currentThread());
        }

        private OwnerReentrantLock getProjectLock(MavenSession session) {
            SessionData data = session.getSession().getData();
            Map<MavenProject, OwnerReentrantLock> locks = data.computeIfAbsent(PROJECT_LOCKS, ConcurrentHashMap::new);
            return locks.computeIfAbsent(session.getCurrentProject(), p -> new OwnerReentrantLock());
        }
    }

View on GitHub (pinned to e4093d4e12)

Solutions

  1. Accept the warning: execution is serialized correctly, the second mojo just waits; verify wall-clock impact before changing anything.
  2. Invoke the module's goals in one lifecycle run (e.g. 'mvn -T 1C install') instead of adding direct goals that race the lifecycle for the same module.
  3. Lower the thread count or drop -T for the affected module set if stalls are measurable.
  4. For plugin authors: avoid forking executions that re-target the same project during parallel builds.

Example fix

# before: direct goal and lifecycle overlap on the same module under -T
mvn -T 4 myplugin:rebuild-module install

# after: single lifecycle pass, no overlapping executions per project
mvn -T 4 install
Defensive patterns

Strategy: validation

Validate before calling

# guard: one lifecycle pass per module; avoid direct goals racing the same project under -T
# instead of: mvn -T 4 direct-goal install
mvn -T 4 install

Prevention

When it happens

Trigger: Parallel build (-T) where two mojo executions for the same project overlap in the schedule — e.g. a direct goal plus a lifecycle phase for the same module, forked executions (compiler:compile with <fork>) re-entering the same project, or an aggregator finishing while a module mojo starts on that project.

Common situations: Mixing direct goal invocations with lifecycle phases for the same module under -T; plugins that fork other lifecycles on the same project; large CI reactors with -T 1C where the scheduler overlaps a module's mojos.

Related errors


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