Community
Participate
Working Groups
Somehow this option got checked, not by me. Ill-chosen default in RC1? But the bug is that even after I uncheck the option, after the full build that is thereby triggered, I _still_ get the error: Severity Description Resource In Folder Location Creation Time 2 The project was not built since its build path is incomplete. Cannot find the class file for org.eclipse.core.resources.IWorkspace. Fix the build path then try building this project com.objfac.xmleditor.new June 10, 2005 9:18:57 AM This is equivalent to "Stop on first error". It makes it impossible to evaluate the effect of removing a plug-in dependency except by changing the source, one file at a time.
Seeing some odd related behavior. I had one file, call it X, with an error indication in my source file (because of the bug). I moved the file to a different folder (drag&drop/refactor). The project was rebuilt and now the file icon in X does not show an error flag, even though if you open it there are plenty. Plus, the build went past that file and found errors in a different file, call it Y. Now a class referenced in file Y appears in the "The project was not built because its build path is incomplete..." message.
Here's the real problem. For some reason the error marker is only being propagated to the file icon in the Package Explorer for the single, seemingly randomly chosen file that is used to create the "project was not built" error message. In fact, the project appears to be built. If I open one of the files that has an unresolved class error, the error markers are there. I just can't see which those files are or how many.
Optional build path issues denote cases where entries cannot be resolved (i.e. missing library). This case is somewhat different, but given our error message, I understand you could think of it as a standard buildpath issue, and expect compilation to pursue its effort. Inconsistent binaries, like the problem described here, are not handled in a resilient fashion by the compiler. It will generally abort from compilation process. Over time we did improve the reporting of the issue, so as to locate the source file which indirectly referenced the missing type. Is this still an issue, if so pls reopen.
