This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 162144 - Go to File not working
Summary: Go to File not working
Status: RESOLVED FIXED
Alias: None
Product: utilities
Classification: Unclassified
Component: Jump To (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Alexey Butenko
URL:
Keywords: REGRESSION
: 162213 162597 (view as bug list)
Depends on: 162580
Blocks:
  Show dependency tree
 
Reported: 2009-04-07 16:08 UTC by Jesse Glick
Modified: 2009-04-17 17:18 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2009-04-07 16:08:19 UTC
In 090406 I notice that with an NBM project open, A-S-O and "project.xml" shows no matches. "project" will show Java
source files with "Project" in the name.
Comment 1 Andrey Yamkovoy 2009-04-07 16:47:17 UTC
Looks like this regression is caused by switching to the Parsing API. 
Comment 2 Andrey Yamkovoy 2009-04-08 15:25:26 UTC
The reason is after switching to Parsing API not whole project folder is used for indexing but source and test roots of it. 
Comment 3 Andrey Yamkovoy 2009-04-08 15:25:54 UTC
*** Issue 162213 has been marked as a duplicate of this issue. ***
Comment 4 Petr Jiricka 2009-04-08 17:34:58 UTC
Just hit the same thing with issue 162213. I must say I think this is quite serious - Go to File is used primarily for
files that are not on your classpath, like project.xml, manifest, persistence.xml, web.xml, faces-config.xml etc.
Comment 5 Jesse Glick 2009-04-08 17:50:39 UTC
I would agree; it seems the primary use case for this action is broken. It is now only useful for opening e.g. icons in
the sourcepath, relatively uncommon.
Comment 6 Alexey Butenko 2009-04-15 09:59:06 UTC
*** Issue 162597 has been marked as a duplicate of this issue. ***
Comment 7 Alexey Butenko 2009-04-15 12:43:13 UTC
changeset eda226cf25f8
Comment 8 Alexei Mokeev 2009-04-15 13:12:16 UTC
Obviously a better fix is possible once issue 162580 will be fixed.
Comment 9 Petr Jiricka 2009-04-15 13:21:39 UTC
Thansk a lot. It looks like the new implementation goes through all folders in the project - what would be the
performance? The main motivation for using the index was to improve the performance, what is the performance now
compared to 6.5?
Comment 10 Alexey Butenko 2009-04-15 13:40:33 UTC
performance should be at least none the worse then in 6.5 . Because already indexed folders and subfolders are omitted. And also filtered out build, dist, 
and all hidden folders and its subfolders.
Comment 11 Petr Jiricka 2009-04-16 13:24:25 UTC
Still does not work quite well for me, I reported issue 162829.

Also, I am looking at the source, and I don't understand one thing: it looks like when the code goes through all the
project directories, the ones that are in source roots are filtered out using condition roots.contains(current).
However, this condition is only applies to the first level of directories, not to the deeper levels. So, when for
example I have a Java web project, which by default places Java sources under src/java, will this directory be correctly
filtered out during the sequential directory search? 
Comment 12 Alexey Butenko 2009-04-16 15:12:44 UTC
You don't have to worry about sources, they should be indexed by Parsing API
Comment 13 Petr Jiricka 2009-04-17 17:18:38 UTC
Not sure if I expressed my doubts clearly, I filed a separate issue 162969 to more clearly describe it. 162969 was
introduced by the fix for this issue.