Sorry, I did not realize that our ASF email server do not support pictures. Regarding the email I sent to DEV <https://lists.apache.org/thread/20t1hjnsomzvfcswr6360q7rgt5q1pyj>, you could not see this picture. I created a page on our Confluence with the picture as well. Please click on the link below. https://cwiki.apache.org/confluence/display/MAVEN/%5BSUREFIRE%5D+Roadmap
Cheers Tibor On Thu, Feb 5, 2026 at 9:37 AM Gerd Aschemann <[email protected]> wrote: > 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 > >
