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.
I see a red exclamation mark next to several Java files saying: "Error parsing file". However the file (and project) builds correctly. Sometimes opening a file with the exclamation point displays no errors. Other times it displays an error about a missing class, which is correctly referenced. Sometimes just opening the file causes the errors to go away. I've verified that the bug occurs on Windows and Macintosh, so it appears to be platform independent. Many other people experience the bug: http://forums.netbeans.org/topic5903-0-asc-0.html All the proposed fixes I've seen don't reliably fix the problem, e.g. removing the cache. It's a serious enough problem that our developers won't use NetBeans until a solution is found. May be related to http://www.netbeans.org/issues/show_bug.cgi?id=168906
Created attachment 87180 [details] Macintosh messages.log
Created attachment 87181 [details] Windows messages.log
Hello, lot of work has been done in this area since 6.7 release. Any chance to try the latest development build of 6.8 and verify that the problem is still there?
I tried the development build and I'm running into some problems with my project file. I'll continue working on it and let you know the outcome.
I spent some more time looking into this and have concluded that many, if not all, the problems are caused by two different projects sharing the same source tree. Since this isn't a supported feature of NetBeans I don't think this is technically a bug. So, you might ask "Why do you have different projects sharing the same source tree". I'm in the process of converting an existing Mac XCode project to NetBeans. The XCode project builds 10 different products out of the same source tree. Rearranging the tree to avoid the NetBeans limitation would break the XCode projects, so I was hoping to avoid the tree rearrangement until I concluded that NetBeans would work for our projects. I am curious to know why the limitation exists since it seems like something that would be useful and not hard to implement.
I finally saw an explanation for the limitation: http://wiki.netbeans.org/FaqSourceRootOverlap Personally, I sort of like the idea of selecting a project (in the project tab) and seeing the files from the point of view of this particular project. This also avoids any ambiguity of which project you're working on when you choose run, build, etc. So, with this approach you'd have a separate pass of the parser (used to build the code completion index and so on) for each of the source files for each project. Only the project you have selected would be kept up to date as you work. When you select a new project in the projects tab it would scan for any updates and parse the necessary files. Based upon my tests performance shouldn't be a problem with this approach.
As designed. Perhaps what the reporter meant to do, assuming rearranging the tree is not an option for now, is to keep the tree under one NB project (with a single compile-time classpath); and, if necessary, write some short Ant targets to package different parts of the output in different JARs. Please use nbusers@netbeans.org for assistance.