Community
Participate
Working Groups
Include breakpoints from the current context into the context. So, they will be available to the other team members. This should be possible using breakpoint import/export features introduced in Eclipse 3.2.
I've always considered this to be the right solution to bug 132092, although I probably wasn't clear enough about it there. I investigated this a while ago and it won't be that hard to implement. OK to mark as duplicate (probably updating the title of that bug)?
Maybe is is implementation details, but this one is actually asking to package breakpoints (including conditional ones) within task data, while bug 132092 is about filtering breakpoint view based on the current context...
It's a bit more than an implementation detail, and the interesting question is whether the loading/unloading breakpoints with contexts is sufficient and removes the need for filtering according to what's in the context. There would be redundancy in the two features because if contexts contained breakpoints there may be little need to use filtering. Thoughts? What we could do is this first, get a feel for it, and then see if we still want filtering for anything.
I have feeling that filtering + disabling would be better idea then import/export + removing.
(In reply to comment #4) > I have feeling that filtering + disabling would be better idea then > import/export + removing. > Agree. Actually, I think auto enabling/disabling would be more useful for me than filtering.
Enabling/disabling is also most compelling to me. The thing it fails to support is sharing of breakpoints (e.g. if you're pair programming), but that's fine for a first pass. However, I wonder if we'll end up with a breakpoints view that's got useless breakpoints from months back specified in it, since the breakpoints for every task will be stored. Also, I wonder if we should be dynamically creating a breakpoint working set for all the breakpoints in the task (similar to change sets). Thoughts?
Post 1.0.
*** Bug 218592 has been marked as a duplicate of this bug. ***
+1 Let me know if you need any help from debug.
Enabling/disabling or otherwise removing/adding was the intent of my original enhancement request (bug#123699). I'm not particularly concerned with the ability to share breakpoints via task context, just enabling/disabling with task activation.
disabling/enabling breakpoints dependant on the task would be the most useful for me
It may be hard to get this completely right on the first pass, but I think there is something we could probably do that would be very useful as a start. For most tasks I would probably not want this feature, but there are some tasks that I keep returning to where I keep recreating the same breakpoints and then later removing them. Perhaps we could add some kind of "save breakpoints" command that would cause breakpoints created since the current task was last activated to be stored locally in a file associated with that task. These breakpoints would then be deleted when the task was deactivated and recreated when it was activated. Having to manually invoke it would reduce the chances of it creating problems for users who don't want/understand the feature, and would allow us to experiment a bit to figure out how this should work. Later we could think about using breakpoint working sets and/or sharing breakpoints on tasks (as a first attempt at sharing, we could just provide a command to attach the breakpoints file to the task and another command to import it).
Just add an option in Task/Context Workbench preferences. Leave it off by default, but when it on, save breakpoints state with the task context.
I don't think that works. A key part of this is *removing* breakpoints when a task is deactivated and I certainly don't want that behaviour for every task. It may turn out to be the right thing to do, but it is not conducive to experimentation, which I think we need here because a) we don't have a consensus on the right thing to do and b) I doubt we have the cycles to implement a full solution, but might be able to squeeze in something like what I proposed.
There is several things. The original bug report been requesting export of breakpoints with the task context for the purpose of sharing them across the team. Has nothing to do with removing them from Workspace. However believe it will be very handy to filter the breakpoint view according to the task context and also restore disable/enable breakpoints upon task activation. Not sure why would you want such feature to work only on some tasks. It is as you would say you want to filter Package Explorer view only for specific tasks...
*** Bug 365144 has been marked as a duplicate of this bug. ***
Just as you can disable editor close removing a file from context, I think there should be a similar option for removing breakpoints to not remove them from a context. But it's more important to me to be able to manage breakpoints with tasks. We task switch about 5 times a day - don't ask - and managing the breakpoint changes is driving us a bit wonky. As far as dissociating breakpoints from task contexts, I can certainly see a use for that - NullPointerException, SWTException, for example, are pretty well on all the time. We have a few of our own key exceptions that are also important. How about something like this: 1. Suppose there are breakpoints set in ECLIPSE with no active task. 2. Task 1 becomes active. 3. Breakpoints are added (or added explicitly to the context, or imported). 4. Task 2 is activated. The breakpoints added in point #3 (Task 1's context) are removed, but the original ones from point #1 are retained. 5. Other breakpoints are added to Task 2's context. 6. Task 1 is activated. The breakpoints from Task 2 are removed and Task 1's are restored. A possible issue is if a global breakpoint from #1 was made part of the Task 2's context, but I think that's operationally acceptable - better than what we have now.
I prefer to have completely independent list of breakpoints for every task. So switching task should export/import them. But I agree that it may be useful to have also some kind of "global" breakpoints. Probably configuration option is the best way to handle this
I originally posted my request on Spring's STS forum, and received a suggestion to follow on this thread - so I'll re-post my use case here: I'm looking for an efficient way to associate/activate only a subset of breakpoints (only the ones related to a active Mylyn task) inside the debug perspective in STS. Is there a way to, say when I'm working on a bug, to add breakpoints to Mylyn context so that this chosen set is available next time around when the task is activated? This way if I switch between the tasks I'll always have only the breakpoints associated with the active task. Currently when I have an active task, once I click on the 'Focus on Active Task' toggle button in the breakpoints view of the Debug perspective, all of the currently visible breakpoints disappear and so I'm forced to carry all the breakpoints, both relevant and not, across all the tasks I keep working on. What is the proper way to achieve the described sought behavior, could someone please shed some light on how it's done? I've been wanting this functionality for years now, so I put my vote in. Simeon
Without proper support for this, the closest thing I can imagine doing now is: * select all breakpoints, right click -> disable * focus the view * select all visible breakpoints, right click -> enable Of course this only works if your context captures all of, and only, the relevant breakpoints.
I proposed this feature in a larger scope ("enabling third-party plugins to contribute to Mylyn context") as a Google Summer of Code project. Please feel free to review the proposal [1] and let me know if you have any suggestions / concern. [1] http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/sebs/26002
This feature request has been accepted for Google Summer of Code 2012, giving me the great opportunity to work on it during the summer. Corresponding wiki page: http://wiki.eclipse.org/Mylyn/Enriching_Task_Context_with_Breakpoints I'm going to keep this bug up to date with project status information.
Here are some questions that came up during our initial investigation. Any thoughts from the community? * which breakpoints should be considered context-related? For example: those added while having an active task, those hit during debug sessions while having an active task, those in a method that is in the context? * should context-related breakpoints be deleted or deactivated upon task deactivation?
My suggestion, as a starting point, is: * that any breakpoints that were in the list of breakpoints immediately prior to switching into a context should not be modified by a task activation or deactivation, except as described below. * that any breakpoints added while a task is active are considered part of the context. * that any breakpoints that are part of the active context are removed on a task deactivation. * that any breakpoints that are part of a task context are added to the existing breakpoint list on a task activation. * Where a breakpoint is in both outside a task context and in a task context, upon task activation, the breakpoint should be replaced (as there can be attributes of the breakpoint that differ within the task context) * Where a breakpoint is in both outside a task context and in a task context, upon task deactivation, the breakpoint should be restored to its pre-activation condition.
+1
Sebastian pushed a review with a proposed implementation here: https://git.eclipse.org/r/#/c/6338/.
While the reviews are ongoing I created an update site with the most recent breakpoints plugin. Any feedback is highly appreciated. Please install the plugin from http://sschmidt.github.com/mylyn-breakpoints/. I tried it with a fresh eclipse juno jee. I would recommend to use a fresh copy, because the installation is going to update Mylyn core with the latest changes from gerrit - which might be a bad idea for your beloved productive ide installation. There are some known issues with the context editor integration: The context editor shows breakpoints only for activated tasks (related to #384365). Also, if you open the context editor, add/delete a breakpoint in another tab, the context editor won't refresh. To see the new/deleted breakpoint reflected in context editor, please reopen it.
This is looking really cool! I think this will be extremely useful. Here are some random thoughts: I'm not sure how useful it is to see breakpoints on the context tab. They should be there, but maybe not at the top, and maybe not expanded by default. Maybe the breakpoints node should say how many breakpoints there are. Or, going in the opposite direction, maybe the breakpoints should actually be shown somehow in the Java model, that is, the method/field/class should have some kind of indicator that there are breakpoints on it that are part of the context. Maybe the breakpoints could be shown as children of that node. I wonder if there's a privacy concern when sharing breakpoints with conditions - the code in the condition might contain private information. Maybe the context tab needs to make it really obvious that there are conditions on the breakpoints, and allow you to see what they are by opening the breakpoint properties. It seems like it would be useful to have the remove from context action in the context menu of the breakpoints view as well. It's a bit odd though - I would actually use this action to make a breakpoint "sticky" so that it doesn't get deleted when the task is deactivated. I wonder if it should have a name that better indicates what it does. Actually, it might be good to have a command to make a breakpoint sticky without removing it from the context. I could imagine that if you have multiple subtasks, you might want them to share some/all of their breakpoints. Has there been any discussion about how to support that? Having commands to make them sticky/not sticky could help with that. The context should include whether a breakpoint is enabled or not. I found a bug: * activate a task * add an exception breakpoint (from Run menu) for NPE * deactivate task * add breakpoint for NPE * activate same task * deactivate task * breakpoint is gone
Sam, thank you very much for your review / comments. Some thought below. (In reply to comment #28) > I'm not sure how useful it is to see breakpoints on the context tab. They > should be there, but maybe not at the top, and maybe not expanded by default. > Maybe the breakpoints node should say how many breakpoints there are. Or, going > in the opposite direction, maybe the breakpoints should actually be shown > somehow in the Java model, that is, the method/field/class should have some > kind of indicator that there are breakpoints on it that are part of the > context. Maybe the breakpoints could be shown as children of that node. Agreed. This is related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=384067 We should decide on how we want users to contribute content to the editor before deciding about this (i.e. cnf extensions + abstract bridges or some kind of new api). Also, I suspect that things become language dependent when we decide to handle specific breakpoint types differently (i.e. add java line breakpoints to java methods, add c++ stuff to c++ stuff, ...). So it might imho be a valid approach to first provide a generic version (current implementation works language independent) and add additional language specific plugins afterwards. > I wonder if there's a privacy concern when sharing breakpoints with conditions > - the code in the condition might contain private information. Maybe the > context tab needs to make it > really obvious that there are conditions on the breakpoints, and allow you to > see what they are by opening the breakpoint properties. Agreed. I'll go ahead and allow to open breakpoint properties from context menu. Not sure about how to highlight these breakpoints though. I'll investigate if there is a language independent way to recognize this. > It seems like it would be useful to have the remove from context action in the > context menu of the breakpoints view as well. It's a bit odd though - I would > actually use this action to make a breakpoint "sticky" so that it doesn't get > deleted when the task is deactivated. I wonder if it should have a name that > better indicates what it does. Actually, it might be good to have a command to > make a breakpoint sticky without removing it from the context. > > I could imagine that if you have multiple subtasks, you might want them to > share some/all of their breakpoints. Has there been any discussion about how to > support that? Having commands to make them sticky/not sticky could help with > that. Very interesting point. How do you solve this right now with resources related to a specific subtask? If you add a breakpoint to a resource and want to share it among other subtasks, are you also interested in sharing the resource amont the subtasks? It will pop up as soon as the breakpoint hits anyway. In this case the Mylyn functionality to copy context from one subtask to another might be sufficient. Than again, I generally like the idea of starring "things" and preventing them from getting removed from context. But would this only be necessary for breakpoints, or also for resources or possible other contributors which might add content to the context? > The context should include whether a breakpoint is enabled or not. Agreed.
(In reply to comment #29) > Agreed. I'll go ahead and allow to open breakpoint properties from context menu. > Not sure about how to highlight these breakpoints though. I'll investigate if > there is a language independent way to recognize this. It might be enough just to indicate with a decoration that there is "extra content" on the breakpoint. This could mean a condition, a hit count, etc.. > > > It seems like it would be useful to have the remove from context action in the > > context menu of the breakpoints view as well. It's a bit odd though - I would > > actually use this action to make a breakpoint "sticky" so that it doesn't get > > deleted when the task is deactivated. I wonder if it should have a name that > > better indicates what it does. Actually, it might be good to have a command to > > make a breakpoint sticky without removing it from the context. > > > > I could imagine that if you have multiple subtasks, you might want them to > > share some/all of their breakpoints. Has there been any discussion about how > to > > support that? Having commands to make them sticky/not sticky could help with > > that. > > Very interesting point. How do you solve this right now with resources related > to a specific subtask? If you add a breakpoint to a resource and want to share > it among other subtasks, are you also interested in sharing the resource amont > the subtasks? It will pop up as soon as the breakpoint hits anyway. In this case > the Mylyn functionality to copy context from one subtask to another might be > sufficient. Than again, I generally like the idea of starring "things" and > preventing them from getting removed from context. But would this only be > necessary for breakpoints, or also for resources or possible other contributors > which might add content to the context? I think breakpoints are special in that they are the only thing that actually gets deleted when you switch tasks, so this issue doesn't arise for resources. The only comparable thing I can think of is when you use a different Git branch for each task, and what usually works well in that case is to create a branch for the parent task and use the same branch for all of the subtasks. Copy context could work in some cases, but you might not want to copy other elements of the context. You also might want to have the set of breakpoints be kept the same between several tasks as breakpoints are added and removed. In some cases it could make sense to store the breakpoints on the parent task, but then in other cases you wouldn't want that. I think having a command to make them sticky or global would accommodate this workflow reasonably well. It would force the user to manually manage that state, but there's probably no way to avoid that. Maybe it would be good to have something like the following set of commands: * make breakpoint global * add to context * add to context and make not global This is getting a little bit complicated though. Another idea would be to have a command to copy only the breakpoints portion of the context. Maybe even an advanced copy dialog where you could check the kinds of elements you want copied (breakpoints, resources, etc.). Really though, this is all pretty advanced use. I'm not sure how often this case would arise in practice, so maybe it's better to leave that for a future enhancement once the basic implementation gets some mileage on it and we have a better sense of what is needed.
A different approach, which would be more consistent with what is done for resources, and would provide a simple solution to the problem I mentioned above of wanting to be able to share breakpoints between different tasks easily, would be to never delete breakpoints, but just disable them instead. Here's a modified version of Randall's proposal, with my changes in italics: (In reply to comment #24) > * that any breakpoints that were in the list of breakpoints immediately prior to > switching into a context should not be modified by a task activation or > deactivation, except as described below. > * that any breakpoints added while a task is active are considered part of the > context. > * _that any breakpoints that were manually enabled while a task is active are considered part of the context._ > * that any breakpoints that are part of the active context -are removed- _have their enablement state persisted and are disabled_ on a task > deactivation. > * that any breakpoints that are part of a task context -are added to the existing- > -breakpoint list- _have their enablement state restored_ on a task activation. > * Where a breakpoint is in both outside a task context and in a task context, > upon task activation, the breakpoint should be replaced (as there can be > attributes of the breakpoint that differ within the task context) > * Where a breakpoint is in both outside a task context and in a task context, > upon task deactivation, the breakpoint should be restored to its pre-activation > condition. Then, we could have a focus button on the breakpoints view that would simply hide all breakpoints that are not part of the context (but perhaps it would make sense to also show breakpoints that are not part of any context). Has this approach been considered?
Actually, I guess you would need to persist and restore all attributes of the breakpoints when switching tasks, so that if a breakpoint is created when one task is active and modified when another is active, the first task's view of the breakpoint will not be affected.
(In reply to comment #31) > Then, we could have a focus button on the breakpoints view that would simply > hide all breakpoints that are not part of the context (but perhaps it would > make sense to also show breakpoints that are not part of any context). > > Has this approach been considered? IMHO, I like the idea for people which are aware of the mylyn debug plugin. However - as we would import new breakpoints unattended and never clean them, I'm not sure if it might become confusing for developers who don't know about the internals of the mylyn debug integration and observe there breakpoints list getting longer and longer over time.
I would think the current approach would also be confusing for people who don't understand it, but that's a good point, that you would be importing other people's breakpoints and they would never be removed. It occurs to me now though that you might not want to import someone else's breakpoints when you use their context, even if they are removed when the task is deactivated. I wonder if there should be some explicit control, such as a command to delete or disable all imported breakpoints for a task. Basically, I think there's a difference between breakpoints you create yourself, and those that you are importing from someone else's context. _Maybe_ it would make sense to have different strategies for dealing with them, so that those you create yourself are only disabled on task deactivation, whereas imported breakpoints are deleted? I don't know, I'm just throwing out my 2 cents.
Unfortunately we won't be able to complete this effort for Mylyn 3.9 but hopefully we can merge the outstanding changes in the next release cycle.
What's the status of this? I would love to get this support in Mylyn.
We need to go ahead and file the CQ. I would suggest to combine all outstanding changes that we want to consume and file one CQ for that. We can still decide to disable the context bridge later but it'd be good to get all changes approved. Does that make sense?
That makes sense to me.
Steffen, by combining the changes do you mean creating one Gerrit review with all the changes? Are the changes all on reviews linked from subtasks?
We can maybe leave the reviews as is but when filing the CQ we should include all code in the same CQ to accelerate processing.
*** Bug 420842 has been marked as a duplicate of this bug. ***
Assigning to myself to file a CQ.
Here's the CQ: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=7904 I decided to include only https://git.eclipse.org/r/6338 and https://git.eclipse.org/r/7193 to speed this up.
The CQ was approved. As discussed on the call today, we should merge the reviews and move the breakpoints support into context.ui instead of having a separate plugin. I wonder if we should add a preference to disable managing breakpoints with task activation?
(In reply to comment #44) > The CQ was approved. As discussed on the call today, we should merge the reviews > and move the breakpoints support into context.ui instead of having a separate > plugin. I might have totally misunderstood the discussion. Before we move/merge stuff can you point me at the code in question? > I wonder if we should add a preference to disable managing breakpoints with task > activation? That probably makes sense.
Sorry, I thought we had decided to merge o.e.m.debug.ui into context.ui. If we don't, then we should make sure the debug.ui plugin is started automatically.
Can you remind me again why we need the startup extension? Did we already try a context startup that would get triggered on first task activation? Sorry, if that was discussed already, I only found a few comments on https://git.eclipse.org/r/#/c/6338/ but not much background on this.
I don't know if we need a startup extension. I just meant that we need to ensure, somehow, that the plugin is started when it should be. It seems like it already is but I want to look into it so that understand how. The reason I suggested merging into context.ui was that I don't see much need for a separate plugin with only a dozen source files. But I'm happy to leave well enough alone if you think it makes sense this way.
(In reply to comment #48) > The reason I suggested merging into context.ui was that I don't see much need > for a separate plugin with only a dozen source files. But I'm happy to leave > well enough alone if you think it makes sense this way. My rule of thumb would be to check if it that would add new dependencies to context.ui. If it brings in debug.ui, JDT or anything like that it should be in a separate bundle to allow consuming context.ui independently of those dependencies.
I've discovered that enabling this causes breakpoints to be lost when projects are closed, because we overwrite the previous set of breakpoints every time we deactivate a task, and breakpoints in closed projects are filtered out of the breakpoint manager. * activate a task * create a breakpoint * deactivate the task * close the project containing the breakpoint * activate the task and deactivate the task again * open the project * activate the task * the breakpoint is not restored Also, if you close a project while a task is active, all the breakpoints in that project which were part of that task's context become global.
Another issue is that if files are modified while a task is not active, when activating the task, the breakpoints will be restored at the wrong locations. If you work on multiple tasks that touch the same files on the same branch (e.g. subtasks of common parent), it could be a problem. Also, if you activate the task before switching to its branch, the breakpoints may be restored at the wrong locations, where they will be saved once the task is deactivated.
Here's an idea that could mostly fix both issues. Breakpoints created by the current user should never be removed, only disabled, whereas breakpoints loaded from contexts shared by other users are removed on task deactivation. This would still prevent the set of breakpoints from growing when retrieving other user's contexts, and would restricting the problems above to those breakpoints (where the second issue is unavoidable on initial import anyway). Maybe we could do this by adding an attribute to each breakpoint's marker to store an identifier for the workspace where the breakpoint was created. A disadvantage is that this might not allow multiple breakpoints at the same location.
I'm moving this to the backlog as it seems that we need to reconsider the design and it's late in the release cycle.
Actually, I wonder if this could be fixed just by removing the breakpoints but keeping their markers so that they continue to be updated.
Sam, can we still merge this feature and add a preference that is disabled by default? I would at least like to make this available to early adopters to gather some feedback since it's one of the bugs with the most votes.
Sure, as long as we make it clear in the preferences that it's experimental and breakpoints may be lost if projects are closed. It's possible we'll want to change the format used to serialize the breakpoints (to address the issue with closed projects) before we enable this by default.
(In reply to comment #56) > Sure, as long as we make it clear in the preferences that it's experimental and > breakpoints may be lost if projects are closed. It's possible we'll want to > change the format used to serialize the breakpoints (to address the issue with > closed projects) before we enable this by default. That sounds reasonable to me. I think we could just add a preferences page under Context with a short message maybe pointing to a bug that collects known issues.
I was going to just add something to the context page. I could add a new page instead but it's less discoverable. What do you think? I'll add the following to the Context section of the user guide once this is merged: bc.. * '''Include breakpoints with task context (Experimental)''' - When this option is checked, each task will have its own set of breakpoints which will be shared when you attach context to the task. Breakpoints created while a task is active will be removed from the workspace on task deactivation and restored the next time the task is activated. This feature has the following limitations: ** Breakpoints in closed projects are deleted from the context on task activation and cannot be recovered. ** Breakpoints stored in context will not have their locations updated as the code changes, so they may be restored at the wrong location.
I guess it's better to have a separate page so it can be contributed from the debug.ui plugin. I'll push a review.
(In reply to comment #48) > I don't know if we need a startup extension. I just meant that we need to > ensure, somehow, that the plugin is started when it should be. It seems like it > already is but I want to look into it so that understand how. All context contributions are started automatically when activating a task. We should keep this in a separate bundle since it adds dependencies on o.e.debug.ui and core. I've created review 22130: 155333: add preference to enable breakpoints in context [Ia7f9453a] https://git.eclipse.org/r/#/c/22130/
I've created the following bug to track the remaining issues: 428378: enable breakpoints in context by default https://bugs.eclipse.org/bugs/show_bug.cgi?id=428378
I've merged the changes and updated the wiki. Managing breakpoints in context is off by default but can be enabled by going to Window > Preferences > Mylyn > Context > Breakpoints. Thanks, Sebastian, for the great contribution! Please report any issues on bug 428378.
