gnodet opened a new pull request, #12680:
URL: https://github.com/apache/maven/pull/12680
## Summary
Fixes several race conditions in the Maven 4.x concurrent builder (`-b
concurrent`) that caused build failures when building large multi-module
projects like Apache Camel (682 modules).
### Changes
- **Thread-safe project references**: Added `ThreadLocal` in the concurrent
`MojoExecutor` so each executor thread uses the correct project for dependency
resolution, instead of the racy `session.getCurrentProject()`. Lifecycle phases
are now recorded directly on the correct project.
- **Thread-safe artifact state on `MavenProject`**:
`setResolvedArtifacts()`, `setArtifactFilter()`, `getArtifacts()`, and
`getArtifactMap()` are now `synchronized` with merge semantics that preserve
artifact file references across concurrent resolutions.
- **Reactor output directory fallback**: When a reactor dependency has been
compiled but not yet packaged, the build now uses its output directory (if it
exists on disk) as the artifact file. This prevents NPEs in downstream compiler
plugin classpath resolution.
- **V4 lifecycle RESOURCES ordering**: Added `after(SOURCES)` constraint to
the `RESOURCES` phase so resource processing happens after source generation,
matching Maven 3 sequential ordering. Without this, resource plugins ran
concurrently with source generators, causing missing resources.
- **after:\* step skip propagation**: Fixed the `after:*` step scheduling
decision to check the phase step itself (not `before:*`). The `before:*` step
is an empty lifecycle setup step that always completes early — checking it
allowed `after:*` steps to execute when the phase was SKIPPED, causing
downstream steps to run out of order (67 module failures).
- **Scope expansion for dependency ordering**: `filterByScope()` now expands
"compile" scope to include `provided` and `system` scoped dependencies,
matching Maven dependency resolution semantics and ensuring provided-scope
reactor dependencies are properly ordered in the build plan.
### Test results
Tested with Apache Camel's 682-module build (`-b concurrent -T1C -Dquickly`):
| Build | Failures | Time |
|-------|----------|------|
| Maven 3, `-T1C -Dquickly` | 0 | 7:04 min |
| Maven 4 concurrent (before fixes) | 67 modules | — |
| Maven 4 concurrent (after fixes) | 0 concurrent-builder failures | 4:38
min |
The 3 remaining failures in the Camel build are pre-existing Maven 4 issues
unrelated to the concurrent builder:
- `camel-netty` / `camel-kudu`: unresolved `${nisse.os.classifier}` property
(missing OS detection extension) — fails identically with the non-concurrent
builder
- `camel-xml-io`: V4 lifecycle allows PACKAGE and UNIT_TEST phases to run in
parallel, but this module has plugins bound to test phases that produce
artifacts needed at package time
## Test plan
- [x] Maven core unit tests pass (`BuildPlanCreatorTest`, full `maven-core`
test suite)
- [x] Apache Camel 682-module build passes with `mvn clean install -b
concurrent -T1C -Dquickly`
- [ ] CI pipeline
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
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]
