| Summary: | [target] removing location results in errors | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Jeff McAffer <jeffmcaffer> | ||||
| Component: | UI | Assignee: | Curtis Windatt <curtis.windatt.public> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | curtis.windatt.public, darin.eclipse | ||||
| Version: | 3.6 | Flags: | darin.eclipse:
review+
|
||||
| Target Milestone: | 3.6 RC1 | ||||||
| Hardware: | PC | ||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 312710 | ||||||
| Attachments: |
|
||||||
|
Description
Jeff McAffer
Listing the included vs excluded bundles was a discussion point from the start of reworking the target platform. We went with included because once the user has defined a target platform as a certain set of bundles we think they will want their target to stay the same. If you have used the content tab to say "These 28 bundles are my target" and then the locations are changed so that those bundles are not available, that is an error. Trying this out, there is a more urgent bug here. You shouldn't have to hack the text file to remove the errors. The included (but not found) bundles are supposed to be listed in the content tab, with error icons. Simply unchecking them should remove them from the include list and remove the errors. However, trying this out, I see that it somehow got broken. Marking this for RC1, even though we are really stretched for time this milestone. Thanks for the clarification. FWIW, the workflow that has users deselecting the now missing bundles from the content tab is very error prone. For example, my target has 500+ bundles in it and there are several dozen bundles to remove. Chances of the user getting this right are slim to none when they have to flip between the two tabs then hunt and deselect. Mitigating approaches: - on the Definition tab where the errors show up have a context menu entry that says "remove from target" or some such. So "thanks, yes, the are problems, toss them" - on the Content tab show error marks beside the bundles with problem and all users to deselect them. Ideally there would be some bulk removal workflow since the numbers here can get very large (In reply to comment #2) > Thanks for the clarification. FWIW, the workflow that has users deselecting > the now missing bundles from the content tab is very error prone. For example, > my target has 500+ bundles in it and there are several dozen bundles to remove. > Chances of the user getting this right are slim to none when they have to flip > between the two tabs then hunt and deselect. Users shouldn't have to hunt, as they all show up with error icons and are at the top of the list. This does require using the content tab. > > Mitigating approaches: > - on the Definition tab where the errors show up have a context menu entry that > says "remove from target" or some such. So "thanks, yes, the are problems, > toss them" > Yes, I could see that, the error management in the target is definitely not as robust as we would like. Errors should be associated in some way to the location and/or plug-in they are caused by. When working with p2 based targets the problem can be even worse as the p2 errors are verbose, but aren't associated with any of the actual target content. This is beyond the scope of anything we are doing in 3.6 > - on the Content tab show error marks beside the bundles with problem and all > users to deselect them. Ideally there would be some bulk removal workflow > since the numbers here can get very large The steps would be: 1) Open the content tab 2) See the errors, select them all 3) Press the deselect button Created attachment 168256 [details]
Fix
Fixes the content group so that it displays entries for missing bundles/features. I had to separate the does not exist status code into two codes for plugins vs features. Also fixes an NPE from updating the counter.
Darin, please review/apply the patch. I opened bug 312710 for an edge case that isn't working. I don't see a simple fix for it, so it won't make it for RC1. There is one trivial change to the tests that didn't get included in the patch. On line 366 of TargetDefinitionFeatureResolutionTests.testMissingMixed(), the returned status code will be IResolveBundle.STATUS_FEATURE_DOES_NOT_EXIST not the plugin does not exist constant. +1 Fixed in HEAD. Filed bug 312718 for a related issue Darin noticed. |