Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 326472 - Can't remove missing plug-in through the Target Definition editor
Summary: Can't remove missing plug-in through the Target Definition editor
Status: VERIFIED FIXED
Alias: None
Product: PDE
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.0   Edit
Hardware: PC Windows 7
: P3 major (vote)
Target Milestone: 3.7 M3   Edit
Assignee: Curtis Windatt CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-28 18:27 EDT by Eric Jain CLA
Modified: 2010-10-27 16:17 EDT (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Jain CLA 2010-09-28 18:27:21 EDT 
Build Identifier: 20100917-0705

...

Reproducible: Always

Steps to Reproduce:
1. delete a plug-in that is referenced from an existing target definition file
2. upon opening that target definition, there is a notice that a "required plug-in could not be found"; deselect that plug-in in the "Content" tab and save
3. re-open the target definition; the missing plug-in is selected again!

Workaround: Open the target definition in a text editor and delete the line that references the missing plug-in.
Comment 1 Curtis Windatt CLA 2010-09-29 09:28:08 EDT 
We'll investigate, having to deselect it is expected, but it should save after deselecting.  Are all other plug-ins on the tab selected?
Comment 2 Eric Jain CLA 2010-09-29 14:06:40 EDT 
Other plug-ins were selected (but not all). After deselecting the missing plug-in I was able to save. This didn't make those plug-ins disappear right away (don't know if it should), but I expected them to be gone when I re-opened the target definition.
Comment 3 Curtis Windatt CLA 2010-09-29 14:18:57 EDT 
(In reply to comment #2)
> Other plug-ins were selected (but not all). After deselecting the missing
> plug-in I was able to save. This didn't make those plug-ins disappear right
> away (don't know if it should),

I doubt they would go away immediately as the tree contents aren't refreshed.  This might be a good improvement, though.

> but I expected them to be gone when I re-opened
> the target definition.

Absolutely.
Comment 4 Curtis Windatt CLA 2010-10-01 15:29:10 EDT 
Fixed in HEAD.  See CachedCheckboxTreeViewer and TargetContentsGroup.

The main problem was caused by a tweak we made in the TargetDefinition implementation which changed when we return missing plug-ins as part of the overall result.  The more the file was modified, the more duplicate includes and other problems would be created.  I've updated the severity to major to reflect that this bug could quickly destroy a target file.

I'm not particularly happy with our API in this area (returning missing plug-ins as part of the getBundles() call), but decided it would be too involved of a change to rewrite the (provisional) api.

At the same time I fixed a few other bugs when you have missing plug-ins related to the count and filtering.
Comment 5 Curtis Windatt CLA 2010-10-27 16:17:57 EDT 
Verified.