Summary: | Changing .classpath doesn't update JDT | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Randy Hudson <hudsonr> |
Component: | Core | Assignee: | Jerome Lanneluc <jerome_lanneluc> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | major | ||
Priority: | P1 | ||
Version: | 2.0 | ||
Target Milestone: | 2.1 M1 | ||
Hardware: | PC | ||
OS: | Windows 2000 | ||
Whiteboard: |
Description
Randy Hudson
2002-07-09 15:48:35 EDT
Good point. We should also consider the MOVE scenario. Actually, I take my previous comment back. The support for detecting .classpath change should capture this scenario. A delta should be notified for Added .classpath file, moved from other one. Need to investigate. Was able to reproduce: you have to rename the .classpath from the Navigator view to see the problem. In addition, I found it difficult to perform this operation in general. For example, I wanted to delete the current .classpath, and then copy the .classpath_win32 to be the new .classpath. (I had to do this because trying to copy straight to .classpath isn't allowed when the file already exists). So, as I delete the existing .classpath, a new one get's places there automatically, even with Autobuild off. Fix won't be ready for 2.0.1. Marking for 2.1 instead. We used to consider only IResourceDelta.CONTENT changes to the .classpath file. Now considering IResourceDelta.MOVED_FROM changes. Randy, for the fact that when you delete a .classpath file it reappears automaticaly, please enter a separate bug. However I doubt this will change as this is by design and this ensures that the classpath is not lost in case of a crash. Verified. |