slawekjaranowski opened a new pull request, #697:
URL: https://github.com/apache/maven-deploy-plugin/pull/697

   * Cache projectsWithDeployExecution list to avoid O(N²) reactor scan
   
   DeployMojo.allProjectsMarked() calls hasDeployExecution() for every reactor 
project on every module invocation. hasDeployExecution() calls 
getPluginsAsMap() for each project, producing O(N²) evaluations in a large 
reactor build (e.g., 4383² ≈ 19.2M calls in a 4383-module project).
   
   Fix: cache the filtered list of projects with deploy executions in the first 
reactor project's plugin context. The list is invariant during a build. Also 
simplify allProjectsMarked() to only check the projects that actually have 
deploy executions, rather than iterating the full reactor and testing the 
disjunction (hasState || !hasDeployExecution).
   
   
   
   * fix: synchronize cache population for parallel builds
   
   The get/check/put on the plugin context map is a TOCTOU race — in parallel 
builds (-T), multiple threads can see the cache as null and each recompute the 
full reactor scan, defeating the cache.
   
   Wrap the compound operation in synchronized(ctx) so only the first thread 
computes and all others reuse the result. Session.getPluginContext() returns 
Map (not ConcurrentMap), so synchronized is the safest choice that does not 
depend on the underlying implementation.
   
   
   
   * refactor: use computeIfAbsent instead of synchronized block
   
   Replace the synchronized get/check/put with a single computeIfAbsent call. 
The plugin context map is a ConcurrentHashMap at runtime, so computeIfAbsent is 
atomic and guarantees single-invocation. Even if the underlying Map 
implementation changed, the worst case is redundant computation of the same 
invariant list — a perf regression, not a bug.
   
   
   
   - https://github.com/apache/maven-deploy-plugin/pull/684


-- 
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