Community
Participate
Working Groups
Using I20100309-0100 * Create breakpoint working sets A and B * Make working set A default * Create a method entry breakpoint (appears in A) * Make working set B default * refactor the method name where the breakpoint is * The breakpoint will move to working set B after being refactored If there is no default working set, it will move to the "Other" category. Looks like the newly created breakpoint gets the current "defaut working set" applied to it rather than retaining its original working set. Same happens for refactored watch points.
Created attachment 240290 [details] Preserving the working set This patch preserves the Working set for the new breakpoint created after method/watchpoint refactor. Refactoring causes the deletion of original breakpoint and creation of new breakpoint with original attributes.
The patch works great for method entry/exit and watchpoints, but does not work for class load breakpoints: 1. create two working sets A and B - set A as the default 2. using the following snippet set breakpoints where indicated: public class Clazz { //class load int field = 10; //watchpoint void method() {} //method breakpoint } 3. set all the breakpoints in working set B (non-default) 4. rename Clazz to Clazz2 - notice that *all* breapoints are moved to the default working set.
Created attachment 240322 [details] Preserving the working set at BreakpointChange level This patch preserves the working set for Line, Field, Method and Class breakpoints during refactor. Original Working set is stored at Breakpoint change level as Class refactor can knock off the original marker attributes.
Works perfectly now. Pushed to: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=0bfc63099d16d40e4ca4fcb5a1e013da07febc8b Thanks Sarika.
Verified with Version: Luna (4.4) Build id: I20140303-2000
