Find dialog makes some assumption on project logical view that is true only for
Java projects. Find looks at the first level of nodes in a project's logical
view and traverses only nodes associated with disk files. This may work for Java
projects but if the first level nodes are for instance logical folders like in
our Make Projects, this heurheurist fails.
Need a way to specify to find what files should be search in a project.
It is possible to define how a given node should be searched. To do so, just add
a SearchInfo object to the node's lookup. Introduction to the SearchAPI and
use-cases is available at
Does the SearchAPI (specifically interfaces SearchInfo and FileObjectFilter and
factory class SearchInfoFactory) fulfil your needs?
Since I consider the reporter's claim invalid and the reporter did not object
against my reply for almost a month, I close this bug report as INVALID.
Feel free to reopen if you actually need some change in the Search API.
Cannnot fully speak for the reporter, but adding SearchInfo into the projects
node helps only for the Find... action. There is another action "Find in
Projects...", which takes SourceGroup(s) of all opened projects and searches
recursively the roots of these SourceGroups, without paying attention to
"SourceGroup.contain". I think this is not correct behaviour.
I can provide you a SourceGroup based SearchInfo that can be used to fix the
"Find in Projects..." action.
Maybe a completely different approach can be taken after the actions redesign,
but I am not sure what is the status of the redesign.
It will be fixed in the version after 5.0.
Then please send waiver request. Thanks.
Well, I do no think this is a P2...
Raising to p2. We would like this fixed and backported to 5.5.1.
The core of this issue is that action Find in Projects does not respect lookup
of the projects' root nodes. So I plan to fix this issue simply by passing the
projects' root nodes to the Find action so that their lookup can be taken into
Unfortunately, it is not possible to get the root nodes displayed in the
Projects view - one can only ask for new copies. So the Find in Projects action
will create a new copy of each project's root node and use these copies for
grabbing information used for searching. This should work but it might increase
memory consumption - this is still to be determined.
I implemented the described changed and ... it does not work. The problem is
that most projects' nodes' lookups do not contain the SearchInfo until the
project's root node is added to the Projects view in the IDE.
I do not have any alternative idea, yet.
"most projects' nodes' lookups do not contain the SearchInfo until the project's
root node is added to the Projects view in the IDE" - really? why?
Anyway I think it would be better for F.i.P. to continue to use SourceGroup but
to pay attention to SG.contains(). (Which, BTW, will be even more important with
Please note that not all projects are 'root' based. Native projects don't have a
source root and don't use SourceGroups. We do create a SearchInfo object (when
the node is displayed!) and sticks it into the lookup and it works well with
Find. Find in Project is the action that doesn't work for us and looking for a
solution that supports something like SearchInfo.
My new idea is to get SearchInfo from the project itself (i.e. not from its root
node) and if the project's lookup does not contain SearchInfo, fallback to the
current implementation, i.e. to the search over SearchGroups.
Let me know if this is an acceptable way of solving this issue. If so, I will
implement and integrate the described change as soon as possible.
yes, I think this solution would work.
I just integrated the change described in my previous post.
I integrated this in two phases because I forgot to update the copyright period
in the first commit.
Great. Please not this is one of the fixes we would like backported to 5.5.1.
The patch seems OK.
This is an API change. It needs to be documented, in SearchInfo and also in
Created attachment 37317 [details]
diff of apichanges.xml - describes the API change
I increased specification version of the Utilities module (1.22 -> 1.23).
Y01 Please try to use hyperlinks to classes you talk about - SourceGroups,
Project, etc. Also make a note in Project's own JavaDoc:
Y02 Is there a test to verify that this contract works for ever? It should be,
otherwise random commits can break this contract in future.
Created attachment 37339 [details]
diff of apichanges.xml - updated
Created attachment 37340 [details]
diff of Javadoc for Project.getLookup()
Created attachment 37341 [details]
diff of Javadoc for SearchInfo
I just committed the documentation and also a test of the Find in Projects action.
Added and modified files:
ProjectsSearchActionTest.java (1.1 - new)
The fix has been backported to 551, correct? Shouldn't it be marked with the
Whiteboard keyword '551_HR_FIX' then?
I think you just need to set TM=5.5.1 if it has already been backported, but I'm
not sure. If it has been backported, was there a commit log somewhere?
I just checked the 551 sources and it doesn't look like it has been backported
yet. But that's the plan, correct?
> I just checked the 551 sources and it doesn't look like it has been
> backported yet. But that's the plan, correct?
Definitely. I talked to mpetras before the weekend and he was starting
preparations of 551 integration. This will be integrated soon.
Very good. Thanks.
I backported the functionality and tests to the 'release551' branch.
Modified and added files:
MockProject.java (126.96.36.199 - new on branch)
MockProjectFactory.java (188.8.131.52 - new on branch)
ProjectsSearchActionTest.java (184.108.40.206 - new on b.)
Additional commit to branch 'release551':