Summary
ModelUtils.mergePluginLists() recomputes orderAfterMerge(...) — and calls setPlugins/flushPluginMap — on every iteration of the parent-plugin loop, even though the loop body already accumulates into assembledPlugins.
src/main/java/org/apache/maven/plugin/resources/remote/ModelUtils.java:81-117
for (Plugin parentPlugin : parentPlugins) {
...
// very important to use the parentPlugins List ...
List<Plugin> results =
ModelUtils.orderAfterMerge(assembledPlugins, parentPlugins, childContainer.getPlugins());
childContainer.setPlugins(results);
childContainer.flushPluginMap();
}
orderAfterMerge walks both full plugin lists (:121-163) with results.contains/indexOf linear scans.
Impact
For P parent plugins this is O(P³) work in the worst case plus repeated map flushes — mostly negligible for typical plugin counts but quadratic-to-cubic during supplemental-model merges with many plugins. The ordering result is identical whether computed once at the end or per-iteration, so the per-iteration call is pure waste.
Suggested fix
Hoist orderAfterMerge(...) + setPlugins/flushPluginMap out of the loop and compute them once after the loop finishes.
Summary
ModelUtils.mergePluginLists()recomputesorderAfterMerge(...)— and callssetPlugins/flushPluginMap— on every iteration of the parent-plugin loop, even though the loop body already accumulates intoassembledPlugins.src/main/java/org/apache/maven/plugin/resources/remote/ModelUtils.java:81-117orderAfterMergewalks both full plugin lists (:121-163) withresults.contains/indexOflinear scans.Impact
For P parent plugins this is O(P³) work in the worst case plus repeated map flushes — mostly negligible for typical plugin counts but quadratic-to-cubic during supplemental-model merges with many plugins. The ordering result is identical whether computed once at the end or per-iteration, so the per-iteration call is pure waste.
Suggested fix
Hoist
orderAfterMerge(...)+setPlugins/flushPluginMapout of the loop and compute them once after the loop finishes.