[ 
https://issues.apache.org/jira/browse/MENFORCER-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17543638#comment-17543638
 ] 

Joseph Walton commented on MENFORCER-420:
-----------------------------------------

That makes sense; adding it to the Helper is a nice way to get an 
execution-scoped cache without having to thread a new object through all the 
calls. I've updated the PR.

One downside is that it will not longer be shared _across_ executions. Our 
current configuration uses several distinct executions with their own 
{{{}<bannedDependencies>{}}}. However, I think adapting our build is 
reasonable, and the isolation from other state is worth it.

> Reuse getDependenciesToCheck results across rules
> -------------------------------------------------
>
>                 Key: MENFORCER-420
>                 URL: https://issues.apache.org/jira/browse/MENFORCER-420
>             Project: Maven Enforcer Plugin
>          Issue Type: Improvement
>          Components: Standard Rules
>            Reporter: Joseph Walton
>            Priority: Minor
>
> We have a build with a significant number of dependencies, and also a large 
> number of {{<bannedDependencies/>}} rules. Together, they lead to a build 
> where Enforcer takes tens of minutes.
> Looking into bottlenecks, we found that 
> {{AbstractBanDependencies#getDependenciesToCheck}} was taking a significant 
> proportion of the build time (tens of percent). This method is called once 
> per rule, so it's recalculating the dependencies for every rule across every 
> execution.
> Introducing a cache, to reuse the dependencies one they'd been calculated for 
> a module, dropped the time spent in banned dependency enforcement by about 
> 75%, which was reflected as a 60% improvement in the time of that build.
> Our local implementation used the {{org.codehaus.plexus.context.Context}} to 
> store the dependencies keyed by the concatenation of {{MavenProject#getId}} 
> and {{searchTransitive}}; there may be a more appropriate scope to avoid edge 
> cases with complex configurations.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

Reply via email to