Community
Participate
Working Groups
We should contribute a search participant for launch configs (references to types).
Deferred
Created attachment 78490 [details] Proposed solution.
If anyone's interested in resurrecting this ghost of the past, I attached my attempt. It finds class references in launch configurations as well as launches (displayed in the Debug View). Double-clicking a launch configuration opens up a launch dialog; double-clicking a launch selects it in the Debug View. One thing it doesn't do is resolve any string substitution variables that might have been used. Also, some of the context menu options don't make much sense, but that's a broader problem with query participants. I look forward to any feedback.
All of the code in the patch is in jdt.ui, ideally your contribution should be made part of JDT debug or maybe even JDT launching if you want debug to consider it. Otherwise I can reassign it to jdt.ui and have them review it if you want it contributed there.
I think I can move it to org.eclipse.jdt.debug.ui. JDT Launching and JDT UI don't see the queryParticipants extension point defined in JDT UI. How's that?
The above should have read "JDT Launching and JDT Debug" can't contribute queryParticipants. Sorry.
Created attachment 79106 [details] Patch for the JDT Debug UI plug-in. Moved to JDT Debug UI plug-in. Added string variable substitution to boot.
could not get the patch to apply to code from HEAD (as of 09/10/2007). Could you recreate a new patch against HEAD?
Created attachment 80018 [details] Patch recreated against HEAD.
Thanks Peter, I will look at it tomorrow.
I had a chance to inspect the patch, following are my comments (take them for what they are worth :) ). 1. (nit-picky) there must be comments for the class and methods 2. there must be curly braces on all control statements (if, for, etc) 3. in the showMatch(..) method of the UIParticipant you iterate over all launch modes in the workspace to find one the is usable by the configuration you want to show in the LCD. It would be better if you only iterated over the modes that the configuration supports using the call config.getType().getSupportedModeCombinations(). 4. searching for launches is not a big win in our books, it could probably be removed 5. you should not assume progress monitors passed in from outside your class are not null (I have been stung with this one before) 6. you could just use a WorkbenchLabelProvider for your UIParticipant instead of creating a the DebugModelDecorator 7. when 'touching' launch configurations you should trap but do nothing with the exceptions, this is because an invalid config could throw an exception (meaning it would get left out of the search results, but should not disrupt the search process). You could probably remove all of the multistatus code 8. If a monitor is canceled you should return from the method and not throw an exception Overall the code is good and works as advertised...just needs a little polishing :)
Created attachment 80481 [details] polished patch polished patch and fix for regex matching where '$' were not escaped properly, and a fix to not care about the project attribute - as configurations can be created/launched without a project attribute.
committed fix to HEAD.
please verify Curtis W, and thanks for the patch Peter
Verified
Excellent, thanks guys!
is this a bugday success story :)?
no, sorry chris :(
