#3692 introduces a more general API to consume analysis results for clients of PMD (analysis listeners). Implementing renderers using a listener is very natural, and in fact, this is what the PR does to renderers with minimal changes.

The Renderer API could be improved in the following ways:

• Renderers could be made stateless, while transient state of the analysis is stored in the listener. This is an improvement as they are basically global mutable objects right now. I don't this this is compatible with the current Renderer interface, so we need a new interface.
• PMD should officially support renderers as an extension point. It should be possible for an external library to package a Renderer and expose it to pmd through the Java Service API. This would allow extracting renderers into different submodules, which would make pmd-core lighter. Currently we have to add a dependency to pmd-core when a new renderer wants to use a parsing/rendering library specific to its file format, for instance.
• [core] Make renderers have access to the context of violations #3904

From meeting protocol (2022-11-22):

• Describe: make more renderers streaming by using temp files
• Describe: make “txt” alias for “text” → compat with maven plugin

• [core] Analysis listeners #3692 removes the field AbstractAccumulatingRenderer#report, instead preferring a new outputReport(Report) method. See how this fits into the new Renderer API and how to be compatible with master