Deprecate JUnit 4 provider with warning message

[Copilot]

JUnit 4 has been outdated for years with clear migration paths available (JUnit 5, JUnit Vintage). This adds a deprecation warning when the JUnit 4 provider is selected.

Changes

• AbstractEclipseTestMojo.java: Log warning when junit4 provider is selected (both createProvisionedInstallation() and createEclipseInstallation() paths)
• JUnit4Test.java: Add test verifying deprecation warning appears in build logs

Warning Message

[WARNING] The JUnit 4 test framework provider is deprecated and may be removed in a future release. 
Please migrate to JUnit 5 or use JUnit Vintage to run JUnit 4 tests. 
See https://github.com/eclipse-jdt/eclipse.jdt.ui/issues/2586 for more information.

The warning triggers whenever Tycho auto-detects or explicitly uses the JUnit 4 provider, appearing in Maven build logs to guide users toward migration.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• testng.org
  • Triggering command: /opt/hostedtoolcache/CodeQL/2.23.1/x64/codeql/tools/linux64/java/bin/java -jar /opt/hostedtoolcache/CodeQL/2.23.1/x64/codeql/xml/tools/xml-extractor.jar --fileList=/home/REDACTED/work/tycho/.codeql-scratch/dbs/java/working/files-to-index15662911680924776615.list --sourceArchiveDir=/home/REDACTED/work/tycho/.codeql-scratch/dbs/java/src --outputDir=/home/REDACTED/work/tycho/.codeql-scratch/dbs/java/trap/java (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

Deprecate the JUnit 4 provider

JUnit4 is already outdated for years and there are good migration path aviable (e.g. Junit vintange) (see also eclipse-jdt/eclipse.jdt.ui#2586)

To acount for this we should do the follwoing:

• deprecate the JUnit 4 provider by let it print a warning in the log when it is used

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[merks]

Do I understand correct that every project in the entire ecosystem MUST migrate their unit tests? Something that the Platform has spent years trying complete? That seems like an absolute non-starter for most project that have far less resource than the platform?

[laeubi]

No that means these projects need to use JUnit5 vintage instead of "native" Junit4 to launch their test... but this is more currently to explore the impact (on platform and tycho itself)

[carstenartur]

Do I understand correct that every project in the entire ecosystem MUST migrate their unit tests? Something that the Platform has spent years trying complete? That seems like an absolute non-starter for most project that have far less resource than the platform?

I am curious who spent "years" on trying to migrate. My experience is there is no real interest in getting a cleanup to do the job.
See

https://github.com/carstenartur/sandbox?tab=readme-ov-file#8-sandbox_junit

[akurtakov]

The real problematic are the cases of JUnit 2(or smth else that predated JUnit 3) concepts (heavy inheritance, manual discovery and mangling of tests to be run, etc. ) wrapped in weird way of JUnit 3 API to be run on JUnit 4.

One left such example is https://github.com/eclipse-jdt/eclipse.jdt.core/blob/8486242e76588947678a6487e33586b6b91f4ddf/org.eclipse.jdt.core.tests.model/src/org/eclipse/jdt/core/tests/RunAllJava13Tests.java#L59 .

Untangling cases like that is what has been taking time (and is done to a huge extend in Platform) and IMO these are not suitable for automatic conversion. A regular test conversion is mostly find-and-replace exersice so not a problem (EDIT: Oversimplified statement!).

[carstenartur]

The real problematic are the cases of JUnit 2(or smth else that predated JUnit 3) concepts (heavy inheritance, manual discovery and mangling of tests to be run, etc. ) wrapped in weird way of JUnit 3 API to be run on JUnit 4.

One left such example is https://github.com/eclipse-jdt/eclipse.jdt.core/blob/8486242e76588947678a6487e33586b6b91f4ddf/org.eclipse.jdt.core.tests.model/src/org/eclipse/jdt/core/tests/RunAllJava13Tests.java#L59 .

Untangling cases like that is what has been taking time (and is done to a huge extend in Platform) and IMO these are not suitable for automatic conversion. A regular test conversion is mostly find-and-replace exersice so not a problem.

I tend to disagree here. You can easily loose tests migrating from junit 3 to 4 with a find and replace approach. Not talking about the change in the order of the parameters in a number of cases. Pre Junit 3 might be worse but the usage of inheritance in jdt.core or jdt.ui is difficult to migrate for a cleanup.
So what you say about really difficult cases might still be true but that a find and replace approach is a solution I do not see here, not using regular expressions. And certainly not for big projects with tons of old code. However - this discussion might not belong here.

[laeubi]

@carstenartur please don't hesitate to discussion the topic further here.
This is actually to get confidence and an overview of the impact of such change, possible mitigations and so on.

As Tycho can even execute cleanup-actions, one approach would be to even discover ways offering your cleanup in an automated way.

Maybe we even found users don't need to migrate at all because we can simply map junit4 > junit5+vintage... I think everything is open at the moment.

[carstenartur]

Imho a deprecation is the right thing at one point. You still can stay with old Eclipse versions if you have to. Ideally you offer help at the same time for migration. To make it technically possible to stay on the old code might be a short time mitigation to some issues but that leads to a shrinking community because young developers hate to learn code from their father or grandfather if that is not buying them a lot of productivity which is not the case here. There is a reason why junit evolved further.

In some corner cases you might see differences in test execution time making use of newer libraries. I once offered a contribution for jdt.ui additionally to display user and system cpu time for the tests. It has been rejected but my tests showed a visible improvement of the accuracy of the test execution time with newer versions of junit.

I do not know what is with dependencies in other non java code parts. I did not check lately: is this resolved?

https://bugs.eclipse.org/bugs/show_bug.cgi?id=570024