Migrate org.eclipse.ui.monitoring.tests from JUnit 4 to JUnit 5

[vogella]

No description provided.

[vogella]

This one fails locally with the following stack trace:

java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at org.eclipse.tycho.surefire.osgibooter.OsgiSurefireBooter.run(OsgiSurefireBooter.java:116)
	at org.eclipse.tycho.surefire.osgibooter.AbstractUITestApplication$1.run(AbstractUITestApplication.java:42)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Testable.lambda$1(E4Testable.java:127)
	at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:132)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:5079)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4548)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1147)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:339)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1038)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:153)
	at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:677)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:339)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:583)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:173)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:185)
	at org.eclipse.tycho.surefire.osgibooter.UITestApplication.runApplication(UITestApplication.java:34)
	at org.eclipse.tycho.surefire.osgibooter.AbstractUITestApplication.run(AbstractUITestApplication.java:129)
	at org.eclipse.tycho.surefire.osgibooter.UITestApplication.start(UITestApplication.java:44)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:219)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:149)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:115)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:467)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:298)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:615)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:563)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1415)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1387)
Caused by: java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at org.apache.maven.surefire.api.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:137)
	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:148)
	at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:88)
	at org.eclipse.tycho.surefire.osgibooter.OsgiSurefireBooter.invokeSureFire(OsgiSurefireBooter.java:195)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	... 31 more
Caused by: java.lang.LinkageError: loader constraint violation: when resolving method 'org.junit.platform.launcher.core.LauncherDiscoveryRequestBuilder org.junit.platform.launcher.core.LauncherDiscoveryRequestBuilder.filters(org.junit.platform.engine.Filter[])' the class loader org.eclipse.tycho.surefire.osgibooter.SurefireLoader @38cf3ae1 of the current class, org/apache/maven/surefire/junitplatform/TestPlanScannerFilter, and the class loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @3b33fff9 for the method's defining class, org/junit/platform/launcher/core/LauncherDiscoveryRequestBuilder, have different Class objects for the type [Lorg/junit/platform/engine/Filter; used in the signature (org.apache.maven.surefire.junitplatform.TestPlanScannerFilter is in unnamed module of loader org.eclipse.tycho.surefire.osgibooter.SurefireLoader @38cf3ae1, parent loader 'app'; org.junit.platform.launcher.core.LauncherDiscoveryRequestBuilder is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @3b33fff9, parent loader 'platform')
	at org.apache.maven.surefire.junitplatform.TestPlanScannerFilter.accept(TestPlanScannerFilter.java:49)
	at org.apache.maven.surefire.api.util.DefaultScanResult.applyFilter(DefaultScanResult.java:87)
	at org.apache.maven.surefire.junitplatform.JUnitPlatformProvider.scanClasspath(JUnitPlatformProvider.java:144)
	at org.apache.maven.surefire.junitplatform.JUnitPlatformProvider.invoke(JUnitPlatformProvider.java:124)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)

No idea what this is, pushing it to the server to see if the issue is only a local one.

[laeubi]

Please see

• Workaround for failure in test execution eclipse-pde/eclipse.pde#2054

it would really be great when pushing such "innocent" changes to watch the results closely and just debug it locally it has already cost me half the day to fix up those things :-\

[vogella]

Please see

• Workaround for failure in test execution eclipse-pde/eclipse.pde#2054

it would really be great when pushing such "innocent" changes to watch the results closely and just debug it locally it has already cost me half the day to fix up those things :-\

As you see from the description in the PR this is a change where I'm aware that there is an issue so it is not "innnovent". I also do not see the relationship to the PDE failure with this change.

The description in eclipse-pde/eclipse.pde#2054 is not clear to me, it sounds like you have to apply a workaround but I do not see in the commit message or PR description why this workaround is necessary, so it is hard for me to consider this issue in the future.

[laeubi]

Feel free to find out yourself and write a holy great user documentation. Beside from that I assume people can read the diff and draw a conclusion.

The issue itself at PDE was also triggered by a JUnit 5 conversion so maybe you can see a correlation here.

[vogella]

Feel free to find out yourself and write a holy great user documentation. Beside from that I assume people can read the diff and draw a conclusion.

The issue itself at PDE was also triggered by a JUnit 5 conversion so maybe you can see a correlation here.

I have seen a lot of work in the last week due to the introduction of JUnit6, so I assume this issue is related. From the diff it looks to me that using plug-in dependencies it currently the preferred workaround if tests are failing to execute.

[github-actions]

Test Results

 3 018 files   3 018 suites   2h 44m 22s ⏱️
 8 229 tests  7 977 ✅ 249 💤 3 ❌
23 607 runs  22 810 ✅ 794 💤 3 ❌

For more details on these failures, see this check.

Results for commit d224a9a.

♻️ This comment has been updated with latest results.

[vogella]

The test failure seems to be reported in #1737 as flacky. Please do not merge this, until I could see if that test can be improved to be stable. The flacky tests are super annoying (for me) and as we have now better tools at our hands, maybe we can stabilize these.

[vogella]

Also flacky but not happening here: #2189

[vogella]

#1737 should be fixed, so that try to build again.

[vogella]

Nice, another know flacky test issue this time from 2023 #868

I have a look