Tibor17 commented on a change in pull request #469: URL: https://github.com/apache/maven-surefire/pull/469#discussion_r805531910
########## File path: maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/TestSetRunListener.java ########## @@ -51,13 +50,13 @@ * @author Kristian Rosenvold */ public class TestSetRunListener - implements RunListener, ConsoleOutputReceiver, ConsoleLogger + implements TestRunListener, ConsoleLogger Review comment: The data flow `fork` -> `plugin` is all about reporting events. The data flow `plugin` -> `fork` is about commands. So this is Command Event based architecture. Similar wordings are in the enterprise world CQRS and Event Sourcing. The first data flow usually sends objects in the form of: - new XxxEvent(new ReportEntry()) - typically test success - new XxxEvent(<string>) - typically std/out from a Thread of a running test - new XxxEvent(<string>) - typically console error, debug Therefore there is such a wording `report` because the provider (InPlugin or fork) sends a report back to the plugin, and the provider is under the plugin in the hierarchy because the plugin is a manager of providers. Now it is visible in the inheritance `ForkingRunListener` -> `RunListener`, `TestOutputReceiver`, `ConsoleLogger`. These are 3 types and three interfaces. I know that you have a problem with the name of class `ForkingRunListener` but it is not mandatory for the developers because the developers and their code operates with abstractions and their code instantiates the object somewhere but the interfaces are use everywhere. The interfaces have different purpose because we do not want `ParallelComputer` to send TEST_SUCCESS of course not, and the PC sends console internal error if any. This is called information hiding. **So there are reports, all these three interfaces are about reports but different group of reports.** Regarding `ForkingRunListener`, whatsoever, do you like `ForkingReportListener` more? From the history, you should know how the code was before. These methods of reports were everywhere. They did not exist one place like it is now in one hotspot. Their implementation was really everywhere, the encoder did not exist in one place and so the encoder's logic was everywhere and it was very hard to maintain the code. Naturally, this situation happened because we are OSS, and in the OSS you start from simple use cases and you do not have time to think of encapsulation, information hiding, and such things cost of maintenance, and such style results in paches and but nit in real fixes. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org