Summary: | Disabled feature shows included children's latest enable version | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Christophe Elek <celek> |
Component: | Update (deprecated - use Eclipse>Equinox>p2) | Assignee: | Dejan Glozic <dejan> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | wassim.melhem |
Version: | 2.0 | ||
Target Milestone: | 2.0.2 | ||
Hardware: | PC | ||
OS: | Windows 2000 | ||
Whiteboard: |
Description
Christophe Elek
2002-10-08 14:48:20 EDT
True, but that means that you (Core) should ignore 'match' for disabled children. *** Bug 24658 has been marked as a duplicate of this bug. *** Christophe, I am moving the defect to you for the following: 1) Modify included feature resolution to always assume match==perfect if the parent is disabled. 2) See if there are no visual side-effects My hunch is that 'best match' resolution for disabled feature also caused other UI defects (in particular, comparing old->new feature trees). Here is the spec: IFeature getFeature() throws CoreException; // <-- currently available IFeature getFeature(boolean exactMatch) throws CoreException; // <-- new API Change the implementation of 'getFeature()' to be: IFeature getFeature() throws CoreException { return getFeature(false); } IFeature getFeature(boolean exactMatch) throws CoreException { int match = exactMatch? <use match value> : PERFECT; ... } After 2.0.2, the new API will be moved to IIncludedFeatureReference because it is not applicable to root-level IFeatureReference. implemented: FeatureReference now contains 2 methods to solve this issue: getFeature() and getFeature(boolean perfectMatch) The object caches and hydrates the 2 possibles instances of the Feature (exactMatch and bestMatch)and returns it appropriatly. Pass to UI for implementation. Fixed in the UI and verified. |