Community
Participate
Working Groups
When I right click on a test to run it as a JUnit plugin test, most of the time it defaults to run the IDE, however I want this test to be run headless. Given that there is no right way to guess which application to run, I would really appreciate if there was a way to have a preference to set the default application to run in those cases. This would represent a really great help for all non-UI involved ppl like us.
Pascal, can't you just choose the application as (Main tab), "No Application <Headless Mode>" This successfully launches the 'org.eclipse.pde.junit.runtime.coretestapplication' which should run things headlessly. Closing this bug as WORKSFORME. If I misunderstand what you want, please reopen.
I believe Pascal is referring to the fact that when you use the context menu to Run as Junit Plug-in Test the "headless app" is not the one selected by default.
How can we read your mind :)? By using a UI application by default, you include both UI and Core applications. PDE UI gives you an option to change this by setting the application and sharing the launch configuration with your friends. Also, we even check your project for a dependency on SWT. If you depend on SWT, we choose the UI application, if you don't, we choose the headless. What else do you want us to do :)?
The part about depending on SWT is good to know. For example, org.eclipse.pde.build.tests is headless. It does not depend on swt directly, but it does use org.eclipse.ui to do an ImportOperation. I'll have to rewrite this to remove the dependency on ui. However, more generally, it may be hard to remove indirect dependencies on swt. One possibility would be to check the Bundle-Activator and see if it extends AbstractUIPlugin. For example, org.eclipse.p2.tests's activator simply implements BundleActivator directly. It does not depend on swt directly but gets it through a dependency on p2.installer.
(In reply to comment #4) > The part about depending on SWT is good to know. For example, > org.eclipse.pde.build.tests is headless. It does not depend on swt directly, > but it does use org.eclipse.ui to do an ImportOperation. I'll have to rewrite > this to remove the dependency on ui. What's wrong with persisting a "PDE Build Tests" launch configuration with the headless application selected? This way, you can at least have things work. > However, more generally, it may be hard to remove indirect dependencies on swt. > One possibility would be to check the Bundle-Activator and see if it extends > AbstractUIPlugin. For example, org.eclipse.p2.tests's activator simply > implements BundleActivator directly. It does not depend on swt directly but > gets it through a dependency on p2.installer. This is a bit tricky but I will rename the bug to talk about enhancing our detection around what application to use. I think what we have currently is pretty adequate and has worked. If we can do anything in the short term, please let us know.
(In reply to comment #5) > What's wrong with persisting a "PDE Build Tests" launch configuration with the > headless application selected? This way, you can at least have things work. I do have such a launch configuration saved in my workspace (though not persisted in the bundle itself). Similarly, I have many SomeTestClass.testBug* launch configurations which each run a specific test method. The issue is when running an individual test method (or suite) for which a launch configuration has not been previously created. Another option is when creating a launch configuration for a given test method, check to see if a launch configuration exists for the Test class in general, then copy that configuration and set the test method on it. Or, the project can save a configuration with a blank test class and this configuration can serve as the template for new ones.
Just so you hear it again from me :-) I know I can change the application, I know I can share launch configs. My scenario is about using the context menu to initiate the launching of a test (right click on a test class, or a package) and having defaults that make sense to run my application (which is what Andrew was saying in the previous comment). As for changing the severity, remember that it represents my point of view and we are being pretty annoyed by this now that we are writing more tests, so I would appreciate if this could be made more than an enhancement.
I agree this is an annoyance. (In reply to comment #3) > How can we read your mind :)? > > By using a UI application by default, you include both UI and Core > applications. PDE UI gives you an option to change this by setting the > application and sharing the launch configuration with your friends. > > Also, we even check your project for a dependency on SWT. If you depend on SWT, > we choose the UI application, if you don't, we choose the headless. The org.eclipse.osgi.tests project does not depend on SWT. If I choose one of the tests (org.eclipse.osgi.tests.bundles.ClassLoadingBundleTests) and Run As -> JUnit Plug-in Test then PDE will create a new launch configuration which defaults to use the org.eclipse.sdk.ide product to launch. Is this working as designed? From your comment it sounds like a bug. > What else do you want us to do :)? > If the tests project does not depend on SWT then it seems reasonable to default to a headless application to launch the test case. Beyond that, I'm not sure how PDE can really make a better guess on what the default application type should be for the test run. If I read Pascal's and others comments correctly they want either of the following: 1) A context menu option JUnit Plug-in Test (headless) 2) A PDE preference to set what the default application type should be when using the context menu option JUnit Plug-in Test. 3) Use a launch configuration stored in the test project as a template when creating new launch configuration for test classes in the same project. Right now I am leaning toward option 3. This way there is no guess work done by PDE.
Changing Version tag to something more believable. Note that this is not a statement about when the enhancement request will be addressed (the Target Milestone field is used for that); the Version tag should be set to the version of Eclipse you were using when you saw the need for the enhancement.
*** Bug 243234 has been marked as a duplicate of this bug. ***
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
Please remove the stalebug flag, if this issue is still relevant and can be reproduced on the latest release.
