Scoped Spring Beans

Some objects must exist only once per application, these are a perfect fit for singleton-scoped beans.
But, some other beans have a lifetime shorter than the application itself.
Additionally, these should exist once per thread that executes (theoretically, because static instances currently prevent parallel threads).

ExecutionContext

OpenRewrite'sExecutionContext is such a class.
TheExecutionContext is populated with data available on every new scan, e.g. Maven configuration information.
Additionally, it contains data with a potentially shorter lifespan (of a recipe execution), e.g. error information or messages.

Moving the creation and destruction (or clean up) of theExecutionContext to Spring would simplify usage and code.
Clients could just inject the current instance using Spring and theExecutionContext is not required to be passed down the object tree.

By providing a dedicated scope likerecipe-scope it would be possible to inject the "right" instance (scoped to current thread and recipe execution) to all objects that share the same or narrower lifespan (Recipe, Action(s), Conditions, ...)

publicMyAction {// The context from current 'recipe-scope' will be injected@AutowiredprivateExecutionContextctx;}

OpenRewrite populates data to the ExecutionContext as early as during the scan of an application.

From SBM's perspective, the ExecutionContext contains data with different scopes: scan and recipe-execution.

This means either:

1. The ExecutionContext is created on each recipe execution and the data normally set during scan (in OR) is kept and passed to the ExecutionContext when the first recipe gets executed. This could be done by keeping this data in a bean scoped toscan which is then used to createExecutionContexts when a recipe starts.
2. The ExecutionContext has itself a scope ofscan and the bean is recreated on each scan. The data with a shorter lifespan needs to be removed after each recipe execution

RewriteMavenParser

TheRewriteMavenParser reads the.mvn/maven.config from project root. This makes this class ascan-scoped bean.
It has to be recreated on each new scan of a project. It also requires access to theExecutionContext.