Community
Participate
Working Groups
Searching a text string with scope "Enclosing project" fails when a JSP is opened. Steps to reproduce: 1. Open a (Plain) Java project, that contains a JSP in a folder and some JavaClasses 2. Open the JSP 3. Hit Ctrl-H, select the tab "File Search", enter a search text that is contained in any file (e.g. "class") 4. select scope "Enclosing Project" Expected result: The search view is opened and the result set is displayed Actual result: The search view is opened, but the result set is empty and "0 matches in project" is displayed Remarks: - Configuration eclipse3.1.1 with WTP 1.0M9 on WinXP - if you run the same search while a Java-Sourcefile or a plain textfile is opened, the expected result is achieved - this worked with WTP 0.7
The scope "Selected resources" does not work either, while the scopes "Workspace" and "Working set..." work as expected
We may only do this advance work if actually in a "dynamic web project". Are you? (You said Java Projects, but I din't know if you meant literally, or just also a java project).?
(In reply to comment #2) > We may only do this advance work if actually in a "dynamic web project". Are > you? > (You said Java Projects, but I din't know if you meant literally, or just also > a java project).? > The problem occurs in both project types - a plain Java project and a Dynamic Web Project. So here is an update steps to reproduce: 1. Create a new Dynamic Web Project (and switch to the J2EE perspective) 2. Create a new class "MyTest" in the src-tree of the Web Project 3. Open the web.xml 4. Hit Ctrl-H, select the tab "File Search", enter "MyTest" as search text 5. Select scope "Enclosing Project" Expected result: The search view is opened and the result set is displayed containing the class "MyTest" Actual result: The search view is opened, but the result set is empty and "0 matches in project" is displayed As a guess: I think, that the selected resources is not determined correctly and so the enclosing project can not be computed...
It is not just JSP's. I have an XML file open as well and have the same problems mentioned in this ticket. Again it works fine for Java file but when in an XML file it doesn't seem to even attempt the search and returns "0 matches in project" I am using eclipse 3.1.1 and wtp 1.0.rc3 (don't know how the rc#'s map to the M# builds or really where all that is documented) Additional info. I just installed a clean eclipse.3.1.1-wtp.1.0.rc3, and found this problem. Prior to this I was using eclipse3.1.1-wtp.0.7 and this problem did not exist, so it it something new in wtp.1.0 releases.
The problem seems to occur if any filetype associated with WTP is opened. I tested it with JSP, HTML, CSS and XML (except build.xml which is associated to the ANT-builder from JDT). In my opinion this is a 1.0-blocker! @Phillip: can you suggest a target milestone?!
I can try to investigate this today. 1.0 is already shutdown (testing for the next week), the soonest this could be fixed is 1.01, but I'll have to go over the criteria for that 1.01 "hotlist" again. Since it's a regression it will probably have more weight.
The problem is in TextSearchPage#getSelectedResourcesScope() The code is expecting IStructuredSelection to be a selection of IResources, which isn't the case if the (WTP) editor has focus (it could be DOM nodes, or another non-resource selection). If you select the file and focus in the navigator view, the search enclosing project works. When a Java file is opened, that selection comes back as TextSelection (not IStructuredSelection), so the code defaults to: else if (isProjectScope) { IProject editorProject= getEditorProject(); if (editorProject != null) { resources.add(editorProject); firstProjectName= editorProject.getName(); } } I believe there's a similar bug open for the "debug on server" action, if you invoke it from the context menu in a WTP editor, no resource can be determined, so the action won't work. I'm assigning to Platform Search for further investigation.
See also bug 118543 ... I suspect we (platform) needs a better story for "multiple" implementations of ISelection.
That's a problem in search, I'm currently looking at it. The 'selected resources' option should only be available if search really understands the editor input. My suggested fix is to disable the option when the editor input is not an IFileEditorInput. The alternative is to try to adapt the editor input to IResource. Opinions? How severe is this problem. Do you want me to backport the fix to 3.1.2?
Phil was referring to bug 116217 in comment 7. (In reply to comment #9) > My suggested fix is to disable the option when the editor input is not an > IFileEditorInput. The alternative is to try to adapt the editor input to > IResource. Opinions? We're not using a non-standard editor input type here, the problem is that the active selection is an IStructuredSelection, just not one containing IResources. TextSearchPage.getSelectedResourcesScope(boolean) doesn't fall back to using the editor's input properly in that case because of an "else". It's possible that reordering the first if-then-else block in TextSearchPage.getSelectedResourcesScope(boolean) to consider the editor's input (since it also checks if it's the active part and returns null otherwise) first would suffice.
(In reply to comment #9) > That's a problem in search, I'm currently looking at it. The 'selected > resources' option should only be available if search really understands the > editor input. > > My suggested fix is to disable the option when the editor input is not an > IFileEditorInput. The alternative is to try to adapt the editor input to > IResource. Opinions? 'selected resources' was disabled with eclipse 3.0 and WTP 0.7, so this is a reasonable suggsetion for me. BUT 'enclosing project' was enabled and fully funtional with WTP 0.7 (as it is with eclipse 3.1 without WTP while a XML-file is opened). IMO: the search dialog should work with WTP 1.0 installed like it does when WTP is not installed. > How severe is this problem. Do you want me to backport the fix to 3.1.2? IMO this is a major loss of functionallity, so yes, this should be backported to 3.1!
(In reply to comment #9) Martin, are we understanding this problem the same way. I'm reading it as the same problem in bug 118543. That is, caused by the fact that we have a selection from the editor that implements BOTH IStructuredSelection AND ITextSelection. It seems a lot of code in tbe base Eclipse assumes "if its a StructuedSelction, we expect it to be an IResource, and if it is not an IResource, we do not know what to do with it". Am I off base and misunderstanding the cause of this problem. Sorry I don't know right off which of your codes to look at. Thanks.
The 3.1.2 fix has to be minmal: What I would fix for 3.1.2 is only to have the 'enclosing projects' selection disabled if we can't adapt the structured selection to IProjects or if we can't adapt the file editor input to a IProject. When the 'enclosing project' option is disabled, the redio button will automatically go to 'Workspace' or selection. The problem of the search implementation in 3.1 is that although the search dialog is responsible to enable/disable the 'enclosing project' radio button, each search page has the code to actually evaluating the enclosing projects. I could fix your problem in File and Java search , but other search pages will still have the problem. I'm assuming that they also just copied the code from the Java/Text pages and have the same issue. For 3.2 I released code that moves all evaluations of enclosing projects to the search dialog. New API on the ISearchPageContainer gives you access to the enclosing projects. For 3.2 I can change the evaluation startegy to always use the editor input, not using then the selected elements. I don't think they should do both. Regarding the discussion in bug 118543, it feel a bit awkward to me that you're mixing IStructuredSelection and a ITextSelection together. I would expect a IStructuredSelection when the selection is in a tree, on elements meaningful in the user interface, selected on purpose by the user. In that case, the user really wants to use this element as the input, and use its enclosing element. Note that this can also be a tree viewer inside an editor (e.g. in PDE).
Created attachment 32670 [details] proposed patch for 3.1.2 Patch that implements your suggestion of testing structured selection and editor input. Only fixes text, but has lower inpact (less risk) than what I suggested. Dani, can you review?
I've verified that the patch fixes the 'Enclosing projects' search for the 'File Search' page.
released patch (attachment 32670 [details]) for 3.1.2. Note that this only fixes the behaviour in File search for 'Enclosing projects', not for 'Selected resources' which will still be active when used on the WTP editor but will not result in matches. released larger fix in 3.2: new API ISearchPageContainer.getEnclosingProjectNames() to be used by all search pages.
For 3.1.2 I've verified the fix inside the Eclipse SDK using M20060109-1200. Markus will verify the fix in combination with WTP.
Verified with M20060109-1200 and wtp 1.0 (200512210855)
*** Bug 126434 has been marked as a duplicate of this bug. ***
Verified with eclipse 3.2 and wtp 1.5.1
