Summary: | Can't turn off Abort build if build path incomplete | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Bob Foster <bob> |
Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
Status: | RESOLVED WONTFIX | QA Contact: | |
Severity: | major | ||
Priority: | P3 | CC: | kent_johnson |
Version: | 3.1 | ||
Target Milestone: | 3.2 M6 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Bob Foster
2005-06-10 12:29:23 EDT
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. |