dashorst opened a new issue, #13590:
URL: https://github.com/apache/maven/issues/13590

   ### Affected version
   
   4.0.0-rc-7, and 4.0.0-SNAPSHOT 4.0.0-20261016.214020-597 
(084c28d756eebbb1cf651ea9b2efd376b724ee01)
   
   ### Bug description
   
   With `-b concurrent` and two or more threads, 
`maven-compiler-plugin:compile` can get a classpath that misses the module's 
dependencies. In the reproducer below this happens on every run. Maven 3.9.16 
and the default builder of Maven 4 build the same project fine.
   
   The trigger appears to be a mojo that requires dependency collection or 
resolution for a *different* scope and is bound to a phase that the concurrent 
builder runs in parallel with `compile`. In our case that is 
`flatten-maven-plugin:flatten` (`requiresDependencyCollection = runtime`), 
bound to `process-resources`. The build plan shows both steps for the same 
project:
   
   ```
   Phase:         after:resources
       Goal:      org.codehaus.mojo:flatten-maven-plugin:1.8.0:flatten (flatten)
       Dependencies (collect): runtime
   Phase:         compile
       Goal:      org.apache.maven.plugins:maven-compiler-plugin:3.16.0:compile 
(default-compile)
       Dependencies (resolve): compile
   ```
   
   The dependency trees that `-X` logs for the module are complete, but the 
classpath handed to javac only contains the runtime-scoped artifacts. In larger 
builds it sometimes also lacks compile-scoped artifacts. So the project's 
artifact set seems to be replaced by the result of the other step's collection 
while `compile` uses it. Because the collection happens before the mojo 
executes, skipping the mojo (`-Dflatten.skip=true`) does not help.
   
   #### Reproducer
   
   `pom.xml`:
   
   ```xml
   <project xmlns="http://maven.apache.org/POM/4.0.0";>
     <modelVersion>4.0.0</modelVersion>
     <groupId>repro</groupId>
     <artifactId>parent</artifactId>
     <version>1.0-SNAPSHOT</version>
     <packaging>pom</packaging>
   
     <modules>
       <module>module</module>
     </modules>
   
     <properties>
       <maven.compiler.release>21</maven.compiler.release>
       <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
     </properties>
   
     <build>
       <plugins>
         <plugin>
           <groupId>org.codehaus.mojo</groupId>
           <artifactId>flatten-maven-plugin</artifactId>
           <version>1.8.0</version>
           <executions>
             <execution>
               <id>flatten</id>
               <phase>process-resources</phase>
               <goals>
                 <goal>flatten</goal>
               </goals>
             </execution>
           </executions>
         </plugin>
       </plugins>
     </build>
   </project>
   ```
   
   `module/pom.xml`:
   
   ```xml
   <project xmlns="http://maven.apache.org/POM/4.0.0";>
     <modelVersion>4.0.0</modelVersion>
     <parent>
       <groupId>repro</groupId>
       <artifactId>parent</artifactId>
       <version>1.0-SNAPSHOT</version>
     </parent>
     <artifactId>module</artifactId>
   
     <dependencies>
       <dependency>
         <groupId>jakarta.ws.rs</groupId>
         <artifactId>jakarta.ws.rs-api</artifactId>
         <version>3.1.0</version>
         <scope>provided</scope>
       </dependency>
     </dependencies>
   </project>
   ```
   
   `module/src/main/java/repro/Uses.java`:
   
   ```java
   package repro;
   
   import jakarta.ws.rs.core.Response;
   
   public class Uses {
       Class<?> type = Response.class;
   }
   ```
   
   Run `mvn clean package -b concurrent -T 2`:
   
   ```
   [ERROR] module/src/main/java/repro/Uses.java:[3,26] package 
jakarta.ws.rs.core does not exist
   ```
   
   Results, 5 runs each (`clean package`, JDK 21, Linux):
   
   | Command | Result |
   |---|---|
   | Maven 3.9.16, `-T 16` | 5/5 pass |
   | Maven 4, default builder, `-T 16` | 5/5 pass |
   | Maven 4, `-b concurrent -T 1` | 5/5 pass |
   | Maven 4, `-b concurrent -T 2`, `-T 4`, `-T 16` | 5/5 fail |
   | Maven 4, `-b concurrent -T 16`, flatten bound to `process-classes` | 5/5 
pass |
   
   Some observations from narrowing it down:
   - With `clean compile` instead of `clean package` the reproducer passes.
   - A single-module project with the same plugin and dependency passes; it 
needs the parent/module reactor.
   - Removing the flatten plugin makes it pass.
   
   In a 67-module project the same problem surfaced as random modules missing 
`provided` and also some compile-scoped dependencies, depending on timing.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to