Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 354644

Summary: Search Component doesn't work for Project and Workspace search scopes
Product: [WebTools] WTP Source Editing Reporter: Keith Chong <keith.chong.ca>
Component: wst.xmlAssignee: Nick Sandonato <nsand.dev>
Status: RESOLVED FIXED QA Contact: Nitin Dahyabhai <thatnitind>
Severity: major    
Priority: P3 CC: cbridgha
Version: 3.4Flags: nsand.dev: pmc_approved? (david_williams)
nsand.dev: pmc_approved? (raghunathan.srinivasan)
nsand.dev: pmc_approved? (naci.dai)
nsand.dev: pmc_approved? (deboer)
nsand.dev: pmc_approved? (neil.hauge)
nsand.dev: pmc_approved? (kaloyan)
cbridgha: pmc_approved+
thatnitind: review+
Target Milestone: 3.3.1   
Hardware: PC   
OS: Windows XP   
Whiteboard: PMC_approved
Attachments:
Description Flags
patch none

Description Keith Chong CLA 2011-08-12 12:35:31 EDT 
When selecting either of the two search scopes "Enclosing Project" and "Workspace", the list of 'components' that should be available is not correct.   The list is the same as that of the "Current Resource" scope.

The scenario is when you are setting a type on an XSD element, you can bring up the Set Type dialog and browse the list of types that are 
1) in the current resource scope, 
2) from other schemas in the enclosing project
3) from schemas in the entire workspace

2) and 3) are broken

This problem happens in 3.4.  (It's fine in 3.2.5 and 3.3.1)

Marking this as major since this is a regression in behaviour and it is a major loss in function.

Not critical, because the workaround is that you can import the schema that contains the desired type first, and then launch the Set Type dialog and use the "Current Resource" scope.
Comment 1 Keith Chong CLA 2011-08-12 15:15:41 EDT 
Correction, this problem happens in 3.3.1.  It's fine in 3.2.5.

I've traced the problem down to the change made in:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=130742
Comment 2 Nick Sandonato CLA 2011-08-25 17:51:27 EDT 
Created attachment 202187 [details]
patch

I think this should better address the case of match-all.
Comment 3 Nick Sandonato CLA 2011-08-29 17:27:58 EDT 
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such.

This was a regression introduced earlier in 3.3.1 and it is a major loss of function.

* Is there a work-around? If so, why do you believe the work-around is insufficient?

import the schema that contains the desired type first, and then launch the Set Type dialog and use the "Current Resource" scope. It's insufficient because people may not realize these steps to be necessary especially if they are used to the existing functionality.

* How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added?

Unit tests have been run and ad hoc testing executed.

* Give a brief technical overview. Who has reviewed this fix?

Essentially, the case where the search name is the match-all '*' was being ignored and the comparison was actually backwards checking that the searched element's name was a '*'. Nitin has reviewed the fix.

* What is the risk associated with this fix?
Low.
Comment 4 Chuck Bridgham CLA 2011-08-30 11:29:26 EDT 
approved
Comment 5 Nick Sandonato CLA 2011-08-30 17:52:03 EDT 
Thanks for the reviews. Code released for 3_3_maintenance and HEAD.