Community
Participate
Working Groups
- build f1 - start with a clean build (may not be strictly necessary) - fire up this Eclipse for the first time - may want to turn off autobuild at this point - File->Import...->External Plugins and Fragments - Next> until you get to the window that gives you a list of the plugins/fragments - Select All - after this completes, open a CVS Repository Exploring perspective - connect to the repository dev.eclipse.org - from HEAD select a number of projects including (but not necessarily limited to) org.eclipse.core.runtime, org.eclipse.core.resources and org.eclipse.core.resources.{win32/linux} depending on which platform you are working on - open a Java perspective - if you turn on autobuild, you will get tons of compiler errors - turn on CVS decorators - notice that the 3 projects named about appear changed - you will have to turn off the filter that hides ".*" files to see these changes - in org.eclipse.core.resources, .classpath and .project are out-of-date - in org.eclipse.core.runtime, .classpath is out-of-date - in org.eclipse.core.resources.linux or org.eclipse.core.resources.win32 (whichever you are using), .classpath is out-of-date - update each of these files with the latest from the repository and all your compiler errors go away NOTES: This happens on linux as well. I know this is doing this backwards (you would normally pick up the projects from the repository first and then 'import external plugins/fragments'). But I never was one to follow the 'status quo'.
Looks like the .classpath and .project are both the "old" ones from the original import and were not replaced by those from the repository. Moving to Platform/VCM for comment.
I believe the problem is caused by PDE (binary project) and how CVS checks out over an existing project (contents are deleted but project is left as is). I suspect PDE causes the old .classpath and .project to be written when it gets the project delta after CVS checks out the project. Now that we have other ways of creating Java projects from remote projects that lack a .project file, we should investigate deleting the entire project on checkout instead of just its contents.
We ran into problems in 0.9 deleting the entire project, it had to do with how other plugins reacted to the deltas. It was particularly a problem for .classpath generation. In general we shouldn't be deleting resources which we know we are just going to create again anyway, for the above and because of the unnecessary performance hit of all the delta generation and management. In any case, I've spoken with Dejan on this general subject, and suggested that he could watch for project description deltas and then check using the Team API if the project is under source control, in which case he could un-PDE it. Moving to PDE.
PDE does not write .classpath and .project after the binary project has been created. The only problem PDE has with this scenario is that the 'binary' project property is not cleared. This causes the 'binary' project decorator to stay even though the entire contents of the project has been replaced and the project does not qualify as binary any more. PDE was about to listen to description changes and clear the flag itself, but we didn't do it yet.
*** This bug has been marked as a duplicate of 18212 ***
