Community
Participate
Working Groups
We've ran into situations when we see stray problem markers in the problems view. These markers cannot be deleted anymore because the code (builder)supposed to take care of them either is not around anymore or simply cannot identify them by type or by some other attribute. Currently, the only way to get rid of these markers is by deleting the metadata. The platform could provide an action which a user could use to remove all problem markers from the problems view. To keep the workspace in a consistent state, it may be that after deleting the markers, the action will have to trigger a full build.
Adding a special filter for specific errors might be a good way to do this but we won't be getting to it for 3.2.
*** Bug 136912 has been marked as a duplicate of this bug. ***
I think it would be good if this could be done within the "Clean..." action. What do you think?
This is what Clean does right now with the java builder but the problems in question are just recreated. We would need some sort of exclusion filter.
(In reply to comment #4) > This is what Clean does right now with the java builder but the problems in > question are just recreated. Not in my case. I removed the builder that created the problems. Thus nobody can recreate the problems. However, a "Clean..." did not remove the problems created by that builder previously.
(In reply to comment #4) > > This is what Clean does right now with the java builder but the problems in > question are just recreated. > > We would need some sort of exclusion filter. > I'm not sure I understand, what problems in question are recreated? Seems the problems in question, here, are that they are not recreated but that the code that created them can no longer remove them. So, why not have code that forcibly removes all errors and warnings? If it was felt this might change behavior too much, it could always be a user option on the 'clean...' dialog. Right? This would also help the few cases I've seen where an 'editor' actually adds them, and the only way to get rid of them is to use the same 'editor' again (e.g the Ant Editor). I think this deserves a high priority for 3.4 ... would improve the 'platform-ness' of the Eclipse platform.
+1 I've been bitten by this particular "feature" a number of times. Having a way to truely "clean" the entire system, regardless of whether the original marker program was there or not would be greatly helpful. This particular issue cropped up on #eclipse as well recently.
This report is just about the problems view - the best we can do for you there is to create an ignore set that can be used as a filter. If you want the markers actually removed from the workspace you will need to log another request to core.
> This report is just about the problems view Why? I don't see any request for filtering these stray problem markers just in the Problems view here, and I don't think such a filter would be worthwhile. If this request for actual removal of these markers is not assigned to the right component, then please reassign.
Perhaps my opening comment was a bit ambiguous due to the repeated references to the problems view but I had hoped that the ensuing discussion clarified the issue. What I really meant is that there should be a way for "orphaned" markers to be removed from the workspace, period. The problems view is just one and the most visible places where these markers are shown.
(In reply to comment #8) > This report is just about the problems view - the best we can do for you there > is to create an ignore set that can be used as a filter. > > If you want the markers actually removed from the workspace you will need to > log another request to core. > I don't see a 'core' component in bugzilla ... so, should this bug be moved to 'resources'?
I actually think this is interesting for the markers view too - problems you see all of the time, are legitimate but don't intend to fix can just be filtered out. This is something people have asked for for a long time. There is a Platform Resources component that a new bug should go in but I still think a UI only filter is worth tracking.
(In reply to comment #12) What does that have to do with this bug report (whose summary is "[Markers] Allow a user to force the removal of all problem markers")? Furthermore, I don't know if Platform/IDE really needs new API from Platform/Resources. So all I could do is open a duplicate of this bug, against Platfrom/IDE, with exactly the same summary and add all the comments, CCs and duplicates again. That does not make sense at all. Tod, please open separate bug if you want to change something in the Markers view filter story. Also, if this cannot be implemented without new API from Resources, then please open a bug with specific requests for them.
They have a problem where they have lost a builder that generated problem markers. There are two possible approaches 1) They just filter them of the problems view out and keep working 2) They wipe out every problem marker in the workspace and then do a build all You are right - we can do either with the existing API but I am not sure if just calling delete on every marker is considered dangerous practice or not by resources. Now the question is if the first one is interesting to anyone. If so they should log another bug. If not then this should suffice as the feature request for the "kill 'em all' action. I'll point out that the chance of inconsistent state may be higher with option 2 as it is unclear what a total rebuild will do as we have no control over the markers generated. Having said that option 1 is only a point solution for the problems view and will not get rid of any in the editor so it might not be enough. I'll add John and Szymon do see if they think we have all we need.
> I'll point out that the chance of inconsistent state may be higher with option > 2 as it is unclear what a total rebuild will do as we have no control over the > markers generated. The problem is that we currently cannot know when a marker (type) is stale. Possible solutions: a) Let the user decide this, i.e. offer a Delete action on all markers in the Markers view, and/or offer a 'Remove markers' option in the Clean dialog that allows the user to remove all markers or all markers of selected marker types. Warn the user about potential inconsistent state or information loss (e.g. when user-created Task markers are removed). b) Add some properties to the marker type and/or builder extension points to declare an "owner" for marker types. The owner must guarantee that it somehow allows the user to remove all the markers it owns. The owner can be - a plug-in (e.g. org.eclipse.ui.ide, which offers the "Tasks" view to remove custom task markers), or - a builder (e.g. the org.eclipse.jdt.core.javabuilder, which removes Java markers on clean). The Clean action could then offer to remove all markers that don't have an owner in the workbench (e.g. because their plug-in is unavailable or because their builder has been removed from a project).
+1 for the kill 'em all approach All the markers I'm interested in can be recreated by doing a clean build. If I had problem markers created some other way I'd want to get rid of them. I assume tasks would be treated differently than 'problem' markers and we'd only be killing errors and warnings.
+1 as well for kill them all. To me that is what a "clean" should do, get you back to a clean slate and then re-run any builders that are necessary. If a user selects clean, they typically are expecting it to re-run all the builders, and re-do any validations as well.
For what it's worth, the original implementation of "clean" did remove all problem markers from the project. However, this caused problems, because problem markers are not necessarily created during a build. Blowing away the markers created by these clients is unexpected, and they have no cue that the marker needs to be regenerated. See bug 58026 for one example of this.
How about adding it as a preference setting. So the user can control the behavior a bit.
And if you enable that preference, the Java builder explodes? In bug 58026, JDT is creating a special problem marker to indicate that the project's build path is invalid and building is not possible. The Java builder checks for the presence of that marker, and does not attempt to build in this case. This is just one example - there could be other places where a tool is generating a problem marker outside the scope of a build, and thus a clean+rebuild would then discard the problem and give the user no way to get it back. I don't have a problem exposing some way to allow a user to remove stale problem markers (at their own risk), I just don't think "clean" is the right place.
Thanks for the insight into JDT John. I can see how tying this in with the builder is dangerous. I think the initial suggestion for a button to automate this is a good one. The button would need to provide an appropriately worded confirmation dialog of course. Good to know about JDTs "special problem marker". Theoretically could the logic to detect if a project's build path is correct be moved into (or called by) the builder? Long term I think adding a property to the marker to say if it's 'cleanable' or not would solve this. That way these 'special' markers could declare that they're exceptional. Having some usage guidelines within marker API javadoc to discourage non-cleanable markers would help too. I assume the vast majority of problems/warnings are things that should be cleanable.
(In reply to comment #21) > Long term I think adding a property to the marker to say if it's 'cleanable' or > not would solve this. Yes, see proposal in comment 15 b). This would even support the scenario where the JDT plug-in was removed from an install and therefore even the JDT build path markers should be removed (because removal of the jdt plug-ins would also remove the "owner" declaration). (In reply to comment #20) > I don't have > a problem exposing some way to allow a user to remove stale problem markers (at > their own risk), I just don't think "clean" is the right place. Project > Clean... is exactly the place where users are trying to remove stale markers. The dialog already says "Clean will discard all build problems [...]". Since this should not be the "standard" way to remove markers, the UI could also be a "Clean Markers..." button in the Clean dialog, which a user can click for a one-time clean up, maybe with options - Clean stale markers // cleans markes without an owner - Clean all markers // with warning that this may leave the workspace in an inconsistent state
I don't think we are going to get a lot of buy in from everyone who supplies builders now to add some sort of special indicator to a marker to show that it is not one that should ever be deleted. Our experience has been that if someone is careful enough to roll with a new feature they are also careful enough to fix a bug. I think we need to look at the real issue here and that is that some builders do not clean up when they are unloaded or leave markers around that cannot be removed. Bugs should be logged against these builders. The delete command in the new markers view is currently set to only run the handler when the entry is editable. If you wanted to you could write a new handler that fires in the opposite case and calls delete. That would also allow for a more fine grained user selection about what they wanted to kill.
(In reply to comment #23) > I think we need to look at the real issue here and that is that some builders > do not clean up when they are unloaded or leave markers around that cannot be > removed. Bugs should be logged against these builders. This logic is too easy. Builders can be unloaded manually at any time by removing them from the ".project" file. Builders can also "disappear" if their plug-in gets deactivated (for whatever reason). AFAIK non of these ways allows the builder to remove any markers it created.
We really have several situations and personally from a users point of view (not a developers point of view) there are a couple of situations that are falling under this one bug. 1. A builder is removed, manually or by deactivation of it's parent plugin, and the error markers stay around. Even by doing a clean. Ideally, if the plugin isn't there and the builder isn't activated, then the error markers should not even be displayed any more. 2. Some builders no matter what leave stale markers. I agree that this is a bug that should be applied against the approporiate builder. However, from a users point of view this is only a long term solution, there is still no way for me to get rid of the markers on my side, short of redoing my workspace and projects. As has already been stated, a "clean" means to me that the entire project or workspace is going to be reset to a clean state, and then all builders for that project are going to run, and the error markers that show up are only going to be valid error markers for those builders that are active. If plugins are using the makers for other purposes then what they were intended for, then this is another issue entirely, and should be addressed appropriately. "clean" should do just what it semanticaly says, clean, so you start from a fresh base before a build happens.
Re comment #25 - I think you're making an incorrect assumption that all "problem" markers are created by builders. This seems like a reasonable assumption from an end user's point of view, but we've never specified this in our API.
After having just dealt with a few hundred files that have had this stale marker problem ... I thought of a potential solution that might be relatively easy and match user expectations. But, pardon my ignorance of markers, but I think some are associate with files, and some with projects, right? My proposal would be that the clean-sweep-delete remove all those associated with files. That'd certainly cover 99% of the cases I personally see. My experience, in coming to this realization, was that for the files I was working with, I could simply delete all (or part) of the contents and then "undo" the contents right back in to the file again, and the erroneous markers would be gone (and new ones created when appropriate). In other words, I'm thinking the way that users get rid of these now is to either delete files, or projects, and re-checkout the project. It would seem to me that any action we do to "simulate" this same action would be "legal" in the realm of marker API's ... it would have to be, right? ... so that might be an easier approach that inventing something new that clients had to do. But, as I admitted at the beginning, I'm not real sure what it is that deletes these markers when contents, files, or projects are deleted. Hope this leads to some concrete ideas. BTW, I _think_ the situation I had is a bit different than has been mentioned so far ... I recently updated my dev. env., still using old workspace, and the builder still existed, but was changed ... so, I'm not sure it still recognized it's own "old" markers to remove them. I'm not sure about that ... but, just thought I'd mention it as something to keep in mind.
Note that in 3.4 we call IMarker#delete so if that is suffecient you will be in business
As we have the handler for it we should also add it to the popup menu as there are cases where it is useful. it's current status as an Easter Egg should be changed
(In reply to comment #28 and comment #29) Scary: Edit > Delete (Delete key) just removes the selected markers without even asking. Filed bug 225531 for this.
Fixed in build >20080409
I confirm that it is now possible to delete problem markers from the problems view by selecting them and hitting the delete key or Edit->Delete. This addresses the request for at least one way to delete stale markers. Perhaps the other concerns (triggering a build, some UI in the clean dialog) and other suggestions will be considered for post 3.4.
This no longer appears to work; trying to delete a marker does nothing at all for me (after the warning dialog). Filed as #136337.
(In reply to comment #33) > Filed as #136337. Er, that's bug 245035.
