Race condition when two Jars being created at the same time

[JasonMathison]

Affected version

3.4.2

Bug description

Sorry if am sending this bug report to the wrong place. While there are MJAR tickets in Jira, I couldn't create a ticket against that project, so sending it here.

We have been dealing with an intermittent problem where occasionally one of the jar files in our build would be non-functional. It turned out that the file was < 10KB, only containing the immediate project output, wtih no dependencies included.

It appears that this could be an issue with the maven JAR plugin when maven is run with -T 3

An example of the JAR file being correctly build looks like this:
09:00:55 [INFO] --- maven-jar-plugin:3.4.2:jar (default-jar) @ maestro-ocelot-log-level-lambda ---
09:00:55 [INFO] Building jar: /var/build/workspace/build-maestro/maestro-ocelot-log-level-lambda/target/maestro-ocelot-log-level-lambda.jar
09:00:55 [INFO]
09:00:55 [INFO] --- maven-shade-plugin:3.6.0:shade (default) @ maestro-ocelot-log-level-lambda ---
09:00:55 [INFO]
09:00:55 [INFO] -------------------------------------------------------
09:00:55 [INFO] T E S T S
09:00:55 [INFO] -------------------------------------------------------
09:00:55 [INFO] Including com.amazonaws:aws-lambda-java-core:jar:1.2.3 in the shaded jar.

followed by lots of shade output and a functional zip file of ~ 55 MBs.

An example of a build that results in a JAR file missing dependences looks like this:

0:35:26 [INFO] --- maven-jar-plugin:3.4.2:jar (default-jar) @ maestro-ocelot-log-level-lambda ---
10:35:26 [INFO] Building jar: /var/build/workspace/build-maestro/maestro-ocelot-log-level-lambda/target/maestro-ocelot-log-level-lambda.jar
10:35:26 [INFO] Building jar: /var/build/workspace/build-maestro/maestro-contracts/target/maestro-contracts-0.0.1.3455-tests.jar
10:35:26 [INFO]
10:35:26 [INFO] --- maven-shade-plugin:3.6.0:shade (default) @ maestro-ocelot-log-level-lambda ---
10:35:26 [INFO]
10:35:26 [INFO] --- maven-install-plugin:3.1.4:install-file (default) @ maestro-contracts ---
10:35:26 [INFO] No artifact matching filter net.logstash.logback:logstash-logback-encoder
10:35:26 [INFO] No artifact matching filter com.inin.messages:inin-messages-events
10:35:26 [INFO] Replacing original artifact with shaded artifact.
10:35:26 [INFO] Replacing /var/build/workspace/build-maestro/maestro-ocelot-log-level-lambda/target/maestro-ocelot-log-level-lambda.jar with /var/build/workspace/build-maestro/maestro-ocelot-log-level-lambda/target/maestro-ocelot-log-level-lambda-0.0.1.3455-shaded.jar

Notice that the shade plugin did not do any work, which I assume means that the JAR file didn't have any dependencies for it to clean up. The JAR file ended up being < 10 KBs.

I found three examples of this issue. Every time that the zip file did not contain any dependencies the log file showed that 2 JAR files were being generated at the same time.

Does this give enough to go on or would there be any tracing that I could enable to help troubleshoot this issue?

[Bukama]

Hi Jason,
just one note about this line

Sorry if am sending this bug report to the wrong place. While there are MJAR tickets in Jira, I couldn't create a ticket against that project, so sending it here.

You did perfectly fine to open an issue here! We are in the process of migrating from JIRA to GitHub Issues. As the first step we have to enable GitHub issues and disable issue creation on JIRA. Plans did not perfectly align of enabling and actual migrating issues - sorry for your inconveniences on that.

[gnodet]

Thanks for the detailed report. After investigating the code paths in both maven-jar-plugin and maven-shade-plugin, I'm confident this is not a bug in the jar plugin itself.

Why maven-jar-plugin is not at fault

In 3.4.2 (which uses Plexus JarArchiver), the mojo is declared @threadSafe = true and each module execution gets its own JarArchiver instance with completely isolated state. The two "Building jar:" lines you see at the same timestamp are two different modules writing to their own target/ directories — that's normal and correct -T behaviour, with no shared files or state between them.

The jar plugin correctly produced the ~10 KB JAR containing your project's own classes. That part worked fine.

The actual bug: shade plugin resolves zero dependencies

Looking at your failing log closely, the shade plugin ran but produced no "Including X in the shaded jar." lines for any dependency — meaning it saw zero resolved artifacts to include, despite your project having runtime dependencies. The "No artifact matching filter..." lines are from your <filters>/<excludes> configuration and are just informational noise.

This is a known class of concurrency bugs in maven-shade-plugin:

• MSHADE-329 (still open): concurrent writes of dependency-reduced-pom.xml produce an infinite loop
• MSHADE-384 (still open): build hangs with -T on JDK 11
• MSHADE-467 (fixed 2024): concurrency problem with dependency-reduced POM

The empty-dependencies symptom you're seeing is a distinct variant — likely project.getArtifacts() returning an empty/incomplete set when two module builds overlap (see also Maven core issue MNG-6843). I've filed apache/maven-shade-plugin#861 to track this specifically.

Workaround

Until the shade plugin issue is fixed:

• Run without -T (single-threaded), or
• Add <forceCreation>true</forceCreation> to your jar plugin config:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-jar-plugin</artifactId>
  <configuration>
    <forceCreation>true</forceCreation>
  </configuration>
</plugin>

This ensures the jar plugin always rebuilds the unshaded JAR even if it considers it up-to-date, eliminating any incremental-build confusion — though it doesn't fix the underlying shade artifact-resolution race.

Closing this issue as "not a jar plugin bug". Please follow apache/maven-shade-plugin#861 for the actual fix.

[gnodet]

Closing as not a maven-jar-plugin issue. See comment above and apache/maven-shade-plugin#861.