Community
Participate
Working Groups
I was running build 2002-01-24 and upgraded to build 2002-02-05. When I started eclipse, it reported the exceptions below while trying to open the 3 type hierarchy perspective I had. I checked, the .classpath file existed in the 01- 24 build, but not in the latest one. Is this a known problem? 1 org.eclipse.core.resources 4 Exception creating editor: Core exception: Core exception: File not found: D:\eclipse- sdk\runtime\eclipse\plugins\org.eclipse.core.boot\.classpath. Log: Wed Feb 06 10:40:32 EST 2002 1 org.eclipse.core.resources 4 Exception creating editor: Core exception: Core exception: File not found: D:\eclipse- sdk\runtime\eclipse\plugins\org.eclipse.core.boot\.classpath. Log: Wed Feb 06 10:40:34 EST 2002 1 org.eclipse.core.resources 4 Exception creating editor: Core exception: Core exception: File not found: D:\eclipse- sdk\runtime\eclipse\plugins\org.eclipse.core.boot\.classpath.
Moving to JDT_UI for comment. The java editor seems to be searching for the .classpath file but it has been deleted in the filesystem. The core exception above is the standard exception that is thrown when IFile#getContents() is called on a file that does not exist in the filesystem.
I think this happend when deleting the projects contents in the background (refresh from local missing). To fix this, core would have to do a refresh from local automatically on startup.
Were you editing your project contents outside of Eclipse? Re: the refresh local on startup- Users are able to do a refreshLocal on startup if they choose by the -refresh command line argument. We do not do it for free since: (1) it can be expensive (2) it can potentially do a lot of work (run builds, etc) (3) normal use-case there is no work to do
These projects were "added" to my workspace using the PDE import plugin wizard. I think at that time, it did not actually make a copy into my workspace directory, but instead actually added files (like the .classpath) into the host directory which I was importing from. So upgrading to a new version overwrote the host directory, causing the .classpath to be removed. The PDE plugin import actually copies the plugin now into the workspace by default. So this problem is less likely to occur. Either way, we should handle this case better. If the file does not exist for the resource .classpath, we should warn the user and default to something. Probably something the JDT team will need to do...not sure if Core can help here.
Adding Philippe to the CC list. What does JDT do when it has been discovered that the classpath file is manually deleted by the user? Is there anything that Core can do to help in this case?
Moving to JDT/Core for comment.
If the .classpath file is missing or not parseable, an exception is thrown. In 1.0, we did silently revert to an empty classpath, but this was condamned as a bad approach by clients.
Clarification: if the .classpath corruption/deletion is notified to jdt/core, then it will add a marker, and silently revert to a default classpath. The log will also be populated each time the .classpath is attempted to be read. Closing. *** This bug has been marked as a duplicate of 16789 ***
I corrupted a .classpath file and I was silently replaced by a valid one when I change a source folder. I don't know if this should be silently changed or if the user should get a warning.
