Conversation
emmartins
approved these changes
Sep 10, 2026
emmartins
left a comment
Collaborator
There was a problem hiding this comment.
Looks good, may I just ask you to create an issue for this change at https://github.com/wildfly/wildfly-bom-builder-plugin/issues ?
Member
Author
|
Ok will do. |
Allows the plugin to run in parallel builds (-T) without Maven emitting the "not marked @threadsafe" warning and degrading to serial execution. Audited the mojo for the usual parallel-build hazards: * No static mutable state. The only static members are the WILDCARD constant and the ModelWriter nested class. * Mojo instances are created per execution, so all @parameter and @component fields are thread confined. This covers the in-place mutation of configuration objects in initializeModel() (parent version) and resolveDependency() (includeDependencies entries). * addDependencyManagement() operates on mavenProject.clone(), and MavenProject.deepCopy() clones the underlying Model, so the reactor's MavenProject is never mutated when the resolver project's dependencies and dependency management are rewritten. * addBuilderManagedDependency() clones each source dependency before changing its version, scope or exclusions, so the source project's dependency management list is not modified in place. * The injected components (ProjectDependenciesResolver, RepositorySystem, ProjectBuilder, ArtifactHandlerManager) are Maven singletons intended for concurrent use; repositorySystemSession and repositories are only read. * MavenProject and MavenSession are injected through the mojo execution scope, which is backed by a ThreadLocal, so each thread gets its own instances. * The BOM is written to the project's own build directory, so concurrent reactor modules cannot write the same file. * OrderedProperties is documented as not thread safe, but a fresh instance is created per execution and never escapes the thread. The one remaining write to state shared between threads is MavenSession.getProjectBuildingRequest(), which lazily creates and then mutates the single ProjectBuildingRequest owned by the MavenExecutionRequest. That happens inside Maven core, every thread writes the same repository session, and the result is immediately copied into a new DefaultProjectBuildingRequest before use. Also add the missing @OverRide on execute(). Signed-off-by: Radoslav Husar <rhusar@ibm.com>
Member
Author
Done #95 and linked. 👍🏼 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Allows the plugin to run in parallel builds (-T) without Maven emitting the "not marked @threadsafe" warning and degrading to serial execution.
Audited the mojo for the usual parallel-build hazards: