Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 344633

Summary:	PDE chooses wrong JRE / EE to launch JUnit plugin tests
Product:	[Eclipse Project] PDE	Reporter:	Michael Rennie <Michael_Rennie>
Component:	UI	Assignee:	Curtis Windatt <curtis.windatt.public>
Status:	VERIFIED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	curtis.windatt.public, daniel_megert, david_williams, jarthana, pwebster, stephan.herrmann
Version:	3.7
Target Milestone:	4.3 M3
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Michael Rennie

2011-05-03 14:53:30 EDT

I as trying to run the LocalSuite from the org.eclipse.debug.tests bundle via context launching, and got the following exception in the log:

junit.framework.AssertionFailedError
	at junit.framework.Assert.fail(Assert.java:47)
	at junit.framework.Assert.assertTrue(Assert.java:20)
	at junit.framework.Assert.assertNotNull(Assert.java:217)
	at junit.framework.Assert.assertNotNull(Assert.java:210)
	at org.eclipse.pde.internal.junit.runtime.NonUIThreadTestApplication.getApplication(NonUIThreadTestApplication.java:93)
	at org.eclipse.pde.internal.junit.runtime.NonUIThreadTestApplication.start(NonUIThreadTestApplication.java:36)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:324)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1386)

The reason is because the JRE the launch shortcut picks to launch the tests is the one from the project, in this case 1.4 and in this scenario will not allow 50% of the bundles in my workspace / target to resolve.

Steps:
1. make sure there is no JUnit plug-in configuration for LocalSuite
2. select the source LocalSuite source file in the package explorer
3. right-click -> Run As -> JUnit Plug-in test

Expected
the tests run

Happens
the mentioned exception

If I go into the launch config dialog and then change the JRE to run the test to 1.6 (or a 1.6 EE) the tests then launch fine. I would assume that PDE could somehow resolve the minimum required JRE (EE) required to run the tests and use that rather than blindly picking the one from the project.

API Tools does something similar to this in our API Baselines. See ApiBaseline#resolveSystemLibrary

Comment 1 Paul Webster

2011-05-03 16:36:00 EDT

This occurs alot, see bug 282562 and bug 341612

I'm not sure what the answer is.  One option (we're using) is to define EEs for our launch configs.

PW

Comment 2 Curtis Windatt

2012-10-26 17:02:55 EDT

I wrote some code for PDE to calculate the default EE and use that in the launch over a default JRE.  Still a couple of problems to fix:

1) Whether fragments in the launch should be checked
2) Checking all the BREEs ends up too restrictive
3) Need to check performance as we end up checking the BREEs of every bundle in the workspace.

http://git.eclipse.org/c/pde/eclipse.pde.ui.git/?h=cwindatt%2Fbug344633_PDE_chooses_wrong_JRE

Comment 3 Curtis Windatt

2012-10-29 15:52:24 EDT

Fixed in master:
http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=66dce08a807338fc4928522be86f7c4e38017ece

1) Fragments are skipped
2) BREE checking is fixed, tests against bundles with 1.5, 1.6, 1.7, CDC, etc.
3) Checking EE against the 520 bundles in my launch takes 15ms.  If the config is opened in the LCD we store the setting so no more lookups happen.

Comment 4 Stephan Herrmann

2012-10-30 10:09:56 EDT

Build I20121029-2000 exhibits failures in JDT/Core tests, which cannot readily be connected to the only fix in JDT/Core that went into that specific build:
http://download.eclipse.org/eclipse/downloads/drops4/I20121029-2000/testresults/html/org.eclipse.jdt.core.tests.compiler_macosx.cocoa.x86_5.0.html

The pattern of failures is: tests are supposed to execute a small
test program and check the printout of the program, which is
unexpectedly empty.

For lack of a better theory let me ask if this bug (also released for the same I-Build) could possibly have an influence on executing programs from within a JUnit-Plug-in-Test on Mac?

Comment 5 Curtis Windatt

2012-10-30 10:17:31 EDT

(In reply to comment #4)
> Build I20121029-2000 exhibits failures in JDT/Core tests, which cannot
> readily be connected to the only fix in JDT/Core that went into that
> specific build:
> http://download.eclipse.org/eclipse/downloads/drops4/I20121029-2000/
> testresults/html/org.eclipse.jdt.core.tests.compiler_macosx.cocoa.x86_5.0.
> html
> 
> The pattern of failures is: tests are supposed to execute a small
> test program and check the printout of the program, which is
> unexpectedly empty.
> 
> For lack of a better theory let me ask if this bug (also released for the
> same I-Build) could possibly have an influence on executing programs from
> within a JUnit-Plug-in-Test on Mac?

It could be related to the launching of the junit plug-in test.  The default JRE used to launch the plug-in test may differ.

Comment 6 Dani Megert

2012-10-31 09:56:43 EDT

Cool! Now I can run new JUnit tests again without manually adjusting the launch config.

Comment 7 Curtis Windatt

2013-01-28 11:59:43 EST

*** Bug 297191 has been marked as a duplicate of this bug. ***