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 used 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 like a cost of maintenance,
and such style results in paches and not 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
