The refactoring branch has already started the idea of simplifying things by using only the JUnit Platform engine. This has already simplified things a lot (~18k lines of code removed so far including tests). As you mentioned, there are some abstraction layers to handle test launching and, more importantly, output and report formatting. You’d be surprised how easily a tiny change in the XML report format can break tools like Cucumber, ArchUnit, or CI integrations etc.. (this etc.., is a lot) Keeping everything backward-compatible is really important. It will make upgrading much smoother since plugin names (Surefire/Failsafe), parameters, and report formats will all stay the same. Switching entirely to the JUnit Platform engine already brings a major change: it drops support for JUnit versions below 4.12. That’s already big enough by itself; changing plugin names or parameters, removing some reporting/output options on top of that would be too disruptive. All the abstraction layers for running the JUnit Platform engine, generating reports, etc., already exist and are familiar to users. There’s no reason to reinvent them. Just moving to a single test engine already simplifies maintenance significantly. I expect even more simplification later, especially around the abstraction layer that manages communication between the Mojo and the forked process, once we have only one execution engine done, that’ll be easier to refine in a second step. As mentioned in this thread, we can’t just drop existing Surefire/Failsafe features. Too many tools rely on them, and doing so would block people from upgrading. Rewriting everything (including the already existing layer, reporting etc..) from scratch doesn’t make sense. Focusing now on modernising/simplifying the internal parts and cleaning legacy code of Surefire/Failsafe is already a big step forward.
cheers Olivier On Wed, 8 Oct 2025 at 05:14, Romain Manni-Bucau <[email protected]> wrote: > > Le mar. 7 oct. 2025 à 21:02, Henning Schmiedehausen > <[email protected]> a écrit : > > > TBH, I am not sure what you are talking about: > > > > On Mon, Oct 6, 2025 at 11:18 PM Romain Manni-Bucau <[email protected]> > > wrote: > > > >> Hi Henning, > >> > >> Please take the time to read the beginning of the thread, the proposal is > >> to drop surefire+failsafe since they are superseeded by junit platform, it > >> literally means supporting all test engines (including junit 3, 4, testng, > >> spock, cucumber, ....) and common reports (mainly xml in our ecosystem - > >> but excludes the maven site). > >> > > > > This is from the junit site: > > > > [image: Screenshot 2025-10-07 at 11.59.05.png] > > > > They literally say "Use failsafe/surefire with junit platform". How is > > that replacing? > > > > junit platform includes a launcher abstracting any test engine, what is > missing is a maven plugin wrapping it like > https://github.com/sormuras/junit-platform-maven-plugin > as mentionned, my proposal is to just develop that part and delegate the > wrapper only > > > > > > -h > > > > > > > Tibor: this will always be the case when you have a dependency and > ultimately you can say the same of Java, at some point you have to decide > what you do own and what you do not. > I do not think it will be that bad cause ultimately their business will > rely on maven as well, several big contributors rely on it too (spring for > ex) and we can still fork if needed which wouldn't be worse than current > surefire codebase so even if I fully weight your point and in a SWOT it > would be a risk, I think it is worth doing it, at least for pom with > modelVersion=4.1.0. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
