Bug 344633 - PDE chooses wrong JRE / EE to launch JUnit plugin tests
Summary: PDE chooses wrong JRE / EE to launch JUnit plugin tests
Status: VERIFIED FIXED
Alias: None
Product: PDE
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.7   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: 4.3 M3   Edit
Assignee: Curtis Windatt CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 297191 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-05-03 14:53 EDT by Michael Rennie CLA
Modified: 2013-01-28 11:59 EST (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Rennie CLA 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 CLA 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 CLA 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 CLA 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 CLA 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 CLA 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 CLA 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 CLA 2013-01-28 11:59:43 EST
*** Bug 297191 has been marked as a duplicate of this bug. ***