Comment 1 Miroslav Shipilov 2020-06-07 23:18:29 EDT

If you run any server instead of the-junitconsole parameter, so that RemoteTestRunner can hook up and write a log, and then tests, then there are no problems.

Comment 2 Dani Megert 2020-06-12 03:41:07 EDT

Nick, do you plan to work on this?

Comment 3 Noopur Gupta 2020-06-12 04:03:44 EDT

Please provide details like Eclipse build id and steps to follow to reproduce the issue.

Also, report if this is a regression i.e. the last known Eclipse build id where it was working.

Comment 4 Miroslav Shipilov 2020-06-14 23:29:22 EDT

Eclipse Platform: 4.15.0.v20200305-0155.

Steps:
1) open Terminal
2) run batch script

//-------------------------------------------------
call set IDEPATH="absolute_path_to_eclipse_folder"

if exist %IDEPATH%\configuration\*.log del /F /Q %IDEPATH%\configuration\*.log

for /f "tokens=*" %%i in ('dir /b  "%IDEPATH%\plugins\org.eclipse.equinox.launcher_*.jar"') Do (call set EQUINOX=%%IDEPATH%%\plugins\%%i)

echo Run with %EQUINOX%

java -Xms512m -Xmx3024m -XX:+UseParallelGC -Dorg.eclipse.emf.common.util.URI.archiveSchemes=ibso -Dru.cft.platform.ide.feedback.send=OFF -classpath %EQUINOX% org.eclipse.equinox.launcher.Main -testLoaderClass org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader -loaderpluginname org.eclipse.jdt.junit4.runtime -application  org.eclipse.pde.junit.runtime.coretestapplication -testpluginname my_test_plugin -testnamefile TestClasses.txt -port 53019 -data . -debugging -consoleLog -junitconsole

//-------------------------------------
where %EQUINOX% - absolute path to "..\plugins\org.eclipse.equinox.launcher_1.5.700.v20200207-2156.jar"

Comment 5 Miroslav Shipilov 2020-06-19 03:59:32 EDT

Noopur Gupta, Is there any news?

Comment 6 Noopur Gupta 2020-06-19 04:56:54 EDT

I am not aware of any specific working of the console mode. I checked the code and I don't see any change in the JUnit console mode code from JDT. 

I see you are running a JUnit plug-in test from the command line. Can you also try your scenario through IDE launch configuration?

Also, it will be helpful if you can try out some previous Eclipse IDE releases and report when this issue started.

Comment 7 Miroslav Shipilov 2020-06-19 08:23:34 EDT

I got a similar behavior by creating a IDE launch configuration. I took the latest version https://www.eclipse.org/downloads/, installed version "Eclipse IDE for Eclipse Committers", created a simple Plug-in Project, created a simple test
Example: 
@Test
public void test1() {
	assertTrue(true);
}

Then I run the test like JUnit Plug-in Test and get a test report, it's ok. Now I add the -junitconsole parameter to the existing JUnit Plug-in Test startup configuration on the Arguments tab in the program arguments field and run it again. 

After starting, I get the lines
%TESTC  1 v2
%TSTTREE1,test1(test.handlers.tests.MyTest),false,1,false,-1,test1(test.handlers.tests.MyTest),,
%TESTS  1,test1(test.handlers.tests.MyTest)
%TESTE  1,test1(test.handlers.tests.MyTest)
%RUNTIME18

and there is no report. If you look closely at the console, the terminated label is missing. If you put the cursor in the console and press Enter, the execution will end.

Comment 8 Noopur Gupta 2020-06-19 10:18:50 EDT

Adding Sarika and Vikas in cc to check the behavior when running the plug-in test with console.

Comment 9 Sarika Sinha 2020-06-19 15:42:01 EDT

Is -junitconsole a standard parameter?

Comment 10 Miroslav Shipilov 2020-06-20 04:19:33 EDT

To run tests, I don't want to raise a third-party server, so I went to the source code and found -junitconsole there.
It's not on the page https://www.cct.lsu.edu/~rguidry/ecl31docs/api/org/eclipse/jdt/internal/junit/runner/RemoteTestRunner.htmlhttps://www.cct.lsu.edu/~rguidry/ecl31docs/api/org/eclipse/jdt/internal/junit/runner/RemoteTestRunner.html in the description. 

Today I went back to the source code and found this

if (fReaderThread != null)   {
				// interrupt reader thread so that we don't block on close
				// on a lock held by the BufferedReader
				// fix for bug: 38955
				fReaderThread.interrupt();
			}
			if (fReader != null) {
				fReader.close();
				fReader= null;
			} 

It looks like an old bug that hasn't been fixed yet https://bugs.eclipse.org/bugs/show_bug.cgi?id=38955

Comment 11 Miroslav Shipilov 2020-06-20 05:06:03 EDT

If anything, I can try to fix this problem myself. However, there is only one solution so far: to avoid changing the default behavior, add a parameter that will prevent the thread from fReaderThread starting. This will be acceptable to me, but I would very much like it to be corrected :)

Comment 12 Miroslav Shipilov 2020-07-05 21:39:12 EDT

I found another solution for myself. Thank you!