remove junit 3 provider code

[olamy]

New feature, improvement proposal

junit before 4.12 is not supported anymore see junit-team/junit-framework#1560

[pzygielo]

Does it mean that Using POJO Tests would also go? I'm not sure - but I think JU3 is used for that.

[olamy]

Does it mean that Using POJO Tests would also go? I'm not sure - but I think JU3 is used for that.

sure will be removed as well see #3187

[Bukama]

I would almost argue to also remove JUnit 4

[elharo]

JUnit 3 still works and is still widely used, including in some of Maven's own code. This just seems likely t impose a lot of needless churn on users.

[olamy]

JUnit 3 still works and is still widely used, including in some of Maven's own code. This just seems likely t impose a lot of needless churn on users.

as said on mailing list you are free to lock the surefire plugin version to the last one supporting junit3, If you are using a very old dependency such junit 3.8 you can certainly lock surefire version to 3.5.4.
Nobod is forcing you to upgrade. pluginManagement/dependencyManagement are here for a reason

[elharo]

I disagree. Any open source project experiences a constant stream of random people shouting to upgrade because, well, just because. This is an example of that. There's no particular reason to drop JUnit 3 here, or anywhere, except that some people like bigger numbers.

[desruisseaux]

The reason is that keeping JUnit 3 is costly: it makes new developments more difficult. I tried to work on a new feature last Saturday (test the different versions of a multi-release project), and stopped in wait for Surefire simplification.

[olamy]

@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!

[khmarbaise]

@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.

Even JUnit 4 is in the meantime in maintainance mode. https://junit.org/junit4/
If someone needs JUnit 3 older versions of maven-surefire/failsafe. can be used... no problem at all...

[sparsick]

@elharo what is your problem with staying on an older Surefire plugin version if you need JUnit 3 support?