Description Dejan Glozic 2002-05-03 21:26:16 EDT

There is a reoccuring problem reported independently by many users who 
selfhostin using binary projects. When A project is imported by overwriting an 
existing binary project, classpath operation reports Java error: "<x> does not 
exist" where 'x' is a project name. 

During the import operation, PDE deletes the project first, then creates a new 
one with the same name. Once project is created and opened, it sets its 
classpath. There is some caching going on in JavaModelManager that causes this 
operation to result in 'does not exist' exception. I traced the problem down to 
the JavaProject.openWhenClosed():

	protected void openWhenClosed(IProgressMonitor pm) throws 
JavaModelException {

		JavaModelManager manager =
			(JavaModelManager) JavaModelManager.getJavaModelManager
();
		if (manager.isBeingDeleted(fProject) || !this.fProject.isOpen
()) {
			throw newNotPresentException();
		} else {
			super.openWhenClosed(pm);
		}
	}

The call to 'isBeingDeleted' returns true, causing newNotPresentException to be 
thrown. Here is a few top levels of the call stack:

org.eclipse.jdt.internal.core.JavaProject.openWhenClosed
(org.eclipse.core.runtime.IProgressMonitor) line: 1677
org.eclipse.jdt.internal.core.JavaProject
(org.eclipse.jdt.internal.core.JavaElement).openHierarchy() line: 499
org.eclipse.jdt.internal.core.JavaProject
(org.eclipse.jdt.internal.core.JavaElement).getElementInfo() line: 288
org.eclipse.jdt.internal.core.JavaProject.getJavaProjectElementInfo() line: 986
org.eclipse.jdt.internal.core.JavaProject.setRawClasspath0
(org.eclipse.jdt.core.IClasspathEntry[]) line: 2043
org.eclipse.jdt.internal.core.SetClasspathOperation.updateClasspath() line: 423

For some reason, JavaModelManager picked that the project has been deleted but 
didn't pick subsequent creation of the project with the same name.

This is a serious problem because it has been experienced by almost everybody 
who rolls the same workspace between builds instead of creating a new one.