Community
Participate
Working Groups
3.3 final. When I right click on a class and say "run as> JUnit plugin test" a new launch configuration is automatically created for me which is cool. However I have found myself having to tweak this launch configuration because classes that were required for my system to run were not here. I think it would be great if the launch configuration could be validated before hand and the test optionally not started (and maybe the launch config dialog opened) if not all dependencies are satisfied. In my particular case the problem came from the fact that the default JRE was being picked and that it was not providing the xml packages.
We do have that capability to auto-validate dependencies. It is off by default because it is an "expensive" operation, and it can be turned on on the Plug-ins/Bundles tab of the launch config. In this case, I think it would be best if PDE actually launched with the JRE associated with the project or EE, rather than the workspace's default JRE.
The fix in comment #1 shouldn't be overly difficult and is not a bad bugday candidate.
As I see it, there are two reasonably obvious solutions to getting the launcher to use the correct JRE. The first involves updating the launch shortcut (e.g. JUnitWorkbenchLaunchShortcut) to include the vm as part of the launch configuration if the project's JRE is different to the workspace's (i.e. to set the relevant attribute on the launch configuration during creation). The second involves updating the launch mechanism itself (and possibly the UI) to pickup the 'correct' JRE. If the UI is also updated to allow the user to be specific about whether to pickup the project JRE or a specific JRE it will make it more consistent with JDT's Java app launching functionality; but this would be a bigger change. My view would be that the simplest and least risky solution would be to leave the launcher config creation as-is, to update the launch mechanism itself to pick up a better default (i.e. of the project), but not to update the UI to be consistent with the JDT. This is likely to have the wierd side-effect that the JUnit's launch JRE will update automatically on change of project JRE UNLESS the user has manually amended the JRE. Anyone have any further thoughts on this?
Created attachment 81253 [details] Possible patch - for v3.4 I20071023-0800 Attached is a possible patch that alters the default to check for the project JRE. Seems to work for the basic scenarios I've tried. Let me know what you think. Specifically, I've NOT checked all other dependent classes (i.e. those that call VMHelper.getVMInstall(ILaunchConfig) ) and I've also not amended a couple of calls to VMHelper.getDefaultVMInstallName() since I'm sure exactly what it's trying to do and there's no launch configuration accessible at that point so would need a little bit of magic to get the information passed around. Hope this is of some use.
Missed out a little bit of context for part of my previous comment. Specifically "... and I've also not amended a couple of calls to VMHelper.getDefaultVMInstallName() ..." refers to two calls in org.eclipse.pde.internal.ui.launcher.JREBlock.
Very nice fix Les. Have to admit I would have done it differently (by calculating the JVM Name in the shortcut), but the way you came up with is more flexible (if the EE changes so will the JVM). Very impressive. I tried my best to break it but it to no avail :) Two extremely minor things I changed. One, in the getVMInstall(ILaunchConfiguration), you had two places you called getDefaultVMInstall(..). Since if the id value from the configuration == null, the vm variable will remain null. Instead of initializing the vm variable in the else statement, I removed the else statement and just left the "if( vm == null ) {" below to initialize the vm object. I figured this way it will work the same way and reduce the amount of code we have. The second was to remove the name variable from getDefaultVMInstall(..). If we use return statements instead of storing the value in a local variable, we will have one less object from the JVM to clean up :) Both of these were extremely minor, just me trying to minimize the lines of code as much as possible. Thanks again for a fantastic patch!
verified on I20071211-0010
