Community
Participate
Working Groups
The WorkingDirectoryBlock class provides a fundamental launching functionality of setting a working directory. Plug-in developers that want to let their users set a working directory when they launch scripts or binaries or whatever have to copy/paste the code or write their own variant for use within their own launch configuration tabs. Please consider taking this class out of JDT and making it API. See bug 214696 for more details.
Too late for 3.4
From my analysis of the code, the only internal references left are for SWTFactory and LauncherMessages. For the SWTFactory references, would the Debug team want those static methods to be copy/pasted into private static methods of WDB or have the implementation details copied into createControl(Composite) directly (I don't know why I prefer the latter, but anyway...)? Thanks.
(In reply to comment #2) > From my analysis of the code, the only internal references left are for > SWTFactory and LauncherMessages. For the SWTFactory references, would the Debug > team want those static methods to be copy/pasted into private static methods of > WDB or have the implementation details copied into createControl(Composite) > directly (I don't know why I prefer the latter, but anyway...)? > Thanks. The messages can still refer to an internal class. I would suggest to use private methods to avoid code duplication (well, at least duplication within the one class...)
Should the WDB go into org.eclipse.debug.ui? No problems there I presume?
(In reply to comment #4) > Should the WDB go into org.eclipse.debug.ui? No problems there I presume? Yes, it is no longer JDT specific.
Darin, there is, what I like to call, a "half API leak" in JavaArgumentsTab. http://help.eclipse.org/stable/nftopic/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/debug/ui/launchConfigurations/JavaArgumentsTab.html#createWorkingDirBlock() As JavaArgumentsTab (and AppletArgumentsTab) is not intended to be subclassed and the references to the internal class is a protected field and not publicly accessible, is there any action that needs to be taken?
This should be safe. This is a protected field who's type will change. Howvever, since no-one can subclass this class, no-one should be able to reference the field, and there are no breaking API changes.
Created attachment 108922 [details] org.eclipse.debug.ui.WorkingDirectoryBlock public API patch v1
Applied patch.
(In reply to comment #9) > Applied patch. Darin, you filed a CQ, right?
I did not file a CQ I see 536 lines added and 516 lines removed, of which 296 lines were identical. So 536 - 296 = 240 new lines. I think this is really just a re-org of existing code rather than a new contribution. Do you agree? I can file a CQ if you think it needs one.
(In reply to comment #11) > I did not file a CQ I see 536 lines added and 516 lines removed, of which 296 > lines were identical. So 536 - 296 = 240 new lines. I think this is really just > a re-org of existing code rather than a new contribution. Do you agree? True, I forgot that the LOC rule doesn't necessarily apply for such copy/paste contributions (as I recall a CQ was not filed for a similar patch of mine that Platform/UI committed in the past). > I can file a CQ if you think it needs one. Nah, it's cool. Thank you for exposing this as an API and sorry for the noise, Darin. :)
Verified.
Removing iplog+ from bug - this indicates an IP contribution in a comment rather than a patch. http://wiki.eclipse.org/Development_Resources/Automatic_IP_Log
