How can we make sure to see the picture, if there is no such attachment? I checked the SMTP body/envelope!
> On 4. Feb 2026, at 18:36, Tibor Digaňa <[email protected]> wrote: > > Hi All, > > (Please make sure you can see the picture under the text or in the attachment) > In regards to my previous email, I decided to explain my goals from high > level perspectives. > In my experience, it is quite easy for the developers to understand little > code changes. > If we are talking about a plan, this perspective cannot be used because the > goals are hard to understand from low level code changes. It is because we > are missing a big picture correlated with the goal itself. > > Therefore I decided to explain a landscape of Surefire first and how the goal > fits to this big picture. > Underneath you can see an application architecture of Surefire landscape > where the left hand side is Plugin group of application components and it's > own processes, and right hand side which consists of Provider impl. > Due to this, we have two isolated runtime instances with distinguished tasks, > however they play one game together, they have to communicate somehow. This > is managed by the event-driven architecture. One can recognize commands and > events. This is an essential part of understanding the architecture in the > Surefire project. > > In the lower right part of the diagram you can see two sets of events > triggered by the Provider meanwhile testing. In the top right part of the > diagram you can see mainly the commands which control the process of Test > Class Execution. Currently we rely on test class execution which is not > always the truth and we are hacking this part due to the TestNG provider > sometimes executes files and suites instead of classes. Therefore you can see > two commands in color, namely "Run Class" in red to be removed and "Run Test > Source" as a new command in green. This would provide us with a chance to > execute anything. > > In the top left part of the diagram you can see corresponding commands > triggered by the plugin. > In yellow you can see the "Events Reporting" process which means that this > requires a change according to my previous email. We would benefit from this > change because the reports would do exactly the report as it is expected > without guessing the test states of the Provider. To accomplish this, we need > to employ a bit more data which would determine the status more reliably. > Namely, we would add the "UniqueID" (a distinct run of the test) and "RunID" > (a distinct ID of the run within re-run feature). Additionally, the processor > of these states should handle objects ("Test***Operation" in green) which > consistently encapsulate the test event name and particular data which is > necessary to create a consistent (and concurrently process the events) into a > report output at real time. > > My goal is to give you a big picture before taking over. I understand that > making small pieces with a sequence of pull-requests would not make you > understandable why and where we are approaching to. > > Feel free to ask me the questions. > Please don't forget that we will have online beer appointment - Maven Apéro > on Friday late evening. > > Cheers > Tibor17 > > > > > -- Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) +49/173/3264070 -- [email protected] -- http://www.aschemann.net
