olamy commented on issue #3185: URL: https://github.com/apache/maven-surefire/issues/3185#issuecomment-3383759077
@elharo In that case, nothing prevents you from using pluginManagement to enforce the last version of the Surefire plugin that still supports this setup. Since users relying on such configurations are already stuck with an old JUnit 3.x version, they can just as well be locked to a compatible Surefire version too. As far as I know, this is precisely what dependencyManagement and pluginManagement are meant for. On the other hand, we really need to stop doing “archaeological code collection.” JUnit 3 is no longer supported and won’t receive any updates. So just stick to the Surefire version that supports it. The same goes for plain POJO tests, unless someone wants to go through the effort of writing a custom JUnit Platform engine. But honestly, in 2025, I really wonder who’s still using that… As @Martin Desruisseaux mentioned here, maintaining backward compatibility comes at a cost. A few months ago, I fixed issues related to multi-threaded tests with JUnit 5, and we still maintain multiple report listener implementations (for JUnit 3, 4, 5, and TestNG). The current interface isn’t well suited for multi-threaded execution and would need significant refactoring which is a lot of code to touch (every single providers). Unsurprisingly, my fixes also caused a few unrelated regressions. By using only the JUnit Platform Engine, we have a single, clean implementation of the report listener that’s well aligned with the target runner. This simplifies maintenance, enables future improvements, and reduces technical debt — essentially phasing out old legacy layers. This kind of cleanup happens all the time in the IT industry. Again, if needed, you can stay on an older version or maintain a dedicated 3.5.x branch — but please don’t block forward progress for everyone else. Onward! -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
