Community
Participate
Working Groups
[M7] Importing of multiple Java projects at once sometimes results in bogus build path errors that go away when the projects are imported one by one. To reproduce this bug: 1. Unzip the attached test.zip 2. Import all three projects at once 3. Delete the projects without deleting the files 4. Import all three projects again After the second import you should see one or more problem: "The project was not built since its build path is incomplete. Cannot find the class file for java.lang.Object."
Created attachment 21568 [details] Test case
The errors are sticky. They don't go away after a clean build or after the project is closed and reopened again. The only thing that helps is to reimport the project separately from others. The problem seems to be caused by a premature build that happens before .classpath is processed. Invalid class path containing just a single entry pointing the root directory of the project is cached as perProjectInfo in JavaModelManager and is never refreshed after that.
Another observed behavior is that Java builder sometimes creates "bin" directory inspite of the project's output folder setting, which points to "classes".
Created attachment 22177 [details] Possible fix I cannot consistently reproduce the problem. However when I saw it, it was because we attempted to read the .classpath file inside a delta for the addition of the .project file, and the .classpath file was not accessible. So we would use the default classpath. Fix consists in using java.io.File to read the .classpath file if not accessible through IResource.
I wonder if a better way to solve this problem would be to make sure that the very first delta includes more files than just .project. I had to implement a workaround for the minimalistic data in my plugin and it was pretty painful. I wouldn't be surprised if this kind of delta breaks many existing plugins.
That would surely solves the problem. Unfortunately Platform Resources is allowed to fire a delta whenever it feels like it (even if the operation is not finished). The contract is that all deltas have been fired at the end of the operation.
+1 for RC2
Released proposed fix.
Verified for 3.1 RC2 using build N20050607-0010 +JDT/Core HEAD. While reproducing the bug is not ez, we could at least produce several occurrences of the behaviors described in comments #1 and #3 on RC1, while multiple tries with RC2 could not raise any of these. The failure rate on RC1 is not bigger than one out of three or four on my machine.
Verified.
Verified with I20050610-0010
