Community
Participate
Working Groups
If you edit the .classpath by hand and make a mistake in the XML, when you open the project, the .classpath file is silently ignored and a nonsensical build happens. When you close the project again, the .classpath is overwritten and you lose your changes. Suggested solution is that opening the project should fail with an error message telling you which line has the error in the .classpath file.
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
