Bugzilla – Full Text Bug Listing
| Summary: | .classpath gets overwritten if there's an XML error | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Brian Slesinsky <bslesins> |
| Component: | Core | Assignee: | Philipe Mulet <philippe_mulet> |
| Status: | VERIFIED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 1.0 | ||
| Target Milestone: | 2.0 F2 | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
|
Description
Brian Slesinsky
The .classpath file is a system file and is not intended to be edited by hand. Moving to Jdt Core fyi A bug in the .classpath is equivalent to no classpath file, a default one is generated then based on the in memory state. Closing The current behavior is non-obvious and most projects cannot possibly compile if the .classfile is bad. At the very least, you need to put up a dialog box explaining that the Java build path was discarded, so that the user can create a new one. The XML parser must be throwing an exception that is suppressed somewhere. Suppressing errors is never a good design practice! I'm disappointed in how this bug is being handled. Fault tolerance is another good design practice. The rule is that this file is managed by JavaCore, not meant to be edited. If this requirement was changed, then yes your claim would be legite, but until it does the current behavior is acceptable, not great but reasonable given the base assumption. Now if you can elaborate one why this file should be editable, then maybe we could reconsider this. It isn't currently on the 2.0 plan, and will move it to LATER for post2.0 reconsideration (so please explain why you think it is a great idea). See bug 8721 for the reason I need to edit .classpath in release 1.0. (The GUI is currently rather tedious for setting up large classpaths based on classpath variables.) I do agree that fault tolerance is good in the sense that the user should not be stuck if .classpath is missing or corrupted. But the current method of recovery makes little sense because Eclipse is unlikely to regenerate a correct .classpath automatically - user intervention is needed, and for that to happen the user must be informed. Also, the best form of recovery may be to get the most recent version of .classpath from a backup rather than starting from scratch. Latest behavior is that if an error is detected after reconciling a change, the change will be ignored, but a marker will be added so as to inform something whent wrong. The actual stack trace is logged to the .log file. Throwing an exception would break pretty much everything... Closing, please reopen if this behavior isn't matching your expectations. Closed Verified |