Maven 2 & 3

Improve performance regarding concrete/dynamic build transitions surrounding plugin executions and report instantiations

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: 2.0.10
  • Fix Version/s: 2.1.0-M1
  • Component/s: Plugins and Lifecycle
  • Labels:
    None
  • Complexity:
    Intermediate
  • Number of attachments :
    0

Description

This is increasing time to build by anywhere from 20% up to a reported 300%, depending on whether reports and aggregator mojos are bound into the lifecycle phases that are executed. Best candidate for fixing this issue is currently to move this transition into the LIfecycleExecutor (out of the PluginManager and PluginParameterExpressionEvaluator) to make the transition less sensitive to report instantiation and forked lifecycles.

There are a couple of other potential performance improvements in the interpolator itself, such as giving a plausible buffer size to the StringWriter embedded for model interpolation, and hanging onto the plexus-interpolator RegexBasedInterpolator instance to prevent continual re-instantiation of the underlying regex Pattern object.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
John Casey added a comment -

Moved transition code to DefautlLifecycleExecutor, away from DefaultPluginManager and PluginParameterExpressionEvaluator, to reduce number of transitions. Also, improved the efficiency of this transition to make it a little smoother, and fixed a small logical error in the transition itself.

Show
John Casey added a comment - Moved transition code to DefautlLifecycleExecutor, away from DefaultPluginManager and PluginParameterExpressionEvaluator, to reduce number of transitions. Also, improved the efficiency of this transition to make it a little smoother, and fixed a small logical error in the transition itself.
Hide
Permalink
John Casey added a comment -

Additionally, I implemented a new ModelInterpolator that uses reflection instead of serialization/deserialization, and String.indexOf(..) to search for expressions inside values instead of regex Pattern/Matcher instances.

Show
John Casey added a comment - Additionally, I implemented a new ModelInterpolator that uses reflection instead of serialization/deserialization, and String.indexOf(..) to search for expressions inside values instead of regex Pattern/Matcher instances.
Hide
Permalink
John Casey added a comment -

Finally, I reimplemented the ModelUtils.cloneXXX(..) methods to use direct object construction instead of the previous attempt to reuse the DefaultModelInheritanceAssembler, or the interim attempt at using serialization/deserializationto get a guaranteed-clean copy.

Show
John Casey added a comment - Finally, I reimplemented the ModelUtils.cloneXXX(..) methods to use direct object construction instead of the previous attempt to reuse the DefaultModelInheritanceAssembler, or the interim attempt at using serialization/deserializationto get a guaranteed-clean copy.

People

  • Assignee:
    John Casey
    Reporter:
    John Casey
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: