Bug 18135

Summary: importing plugins resulted in 9MB of errors added to log
Product: [Eclipse Project] JDT Reporter: Adam Kiezun <akiezun>
Component: CoreAssignee: Philipe Mulet <philippe_mulet>
Status: VERIFIED FIXED QA Contact:
Severity: major    
Priority: P3 CC: dejan
Version: 1.0   
Target Milestone: 2.0 F2   
Hardware: PC   
OS: Windows 2000   
Whiteboard:

Description Adam Kiezun CLA 2002-05-29 05:06:55 EDT
20020528
i tried to import existing binary projects.

the first problem logged was (after that there was 9MB more of similar entries)
marking as major

Java Model Exception: Core Exception [code 271] File not found: 
d:\eclipseWorkbench5\plugins\org.eclipse.core.boot\.classpath.
	at org.eclipse.jdt.internal.core.JavaProject.loadClasspath
(JavaProject.java:1582)
	at org.eclipse.jdt.internal.core.JavaProject.getRawClasspath
(JavaProject.java:1231)
	at org.eclipse.jdt.internal.core.JavaProject.computeExpandedClasspath
(JavaProject.java(Compiled Code))
	at org.eclipse.jdt.internal.core.JavaProject.computeExpandedClasspath
(JavaProject.java(Compiled Code))
	at org.eclipse.jdt.internal.core.JavaProject.computeExpandedClasspath
(JavaProject.java(Compiled Code))
	at org.eclipse.jdt.internal.core.JavaProject.getExpandedClasspath
(JavaProject.java:920)
	at org.eclipse.jdt.internal.core.JavaProject.getExpandedClasspath
(JavaProject.java:907)
	at 
org.eclipse.jdt.internal.core.SetClasspathOperation.updateAffectedProjects
(SetClasspathOperation.java:490)
	at 
org.eclipse.jdt.internal.core.SetClasspathOperation.generateClasspathChangeDelta
s(SetClasspathOperation.java:361)
	at org.eclipse.jdt.internal.core.SetClasspathOperation.updateClasspath
(SetClasspathOperation.java:458)
	at org.eclipse.jdt.internal.core.SetClasspathOperation.executeOperation
(SetClasspathOperation.java:212)
	at org.eclipse.jdt.internal.core.JavaModelOperation.execute
(JavaModelOperation.java:292)
	at org.eclipse.jdt.internal.core.JavaModelOperation.run
(JavaModelOperation.java:500)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java
(Compiled Code))
	at org.eclipse.jdt.internal.core.JavaModelManager.runOperation
(JavaModelManager.java:1186)
	at org.eclipse.jdt.internal.core.JavaElement.runOperation
(JavaElement.java:576)
	at org.eclipse.jdt.internal.core.JavaProject.setRawClasspath
(JavaProject.java:2014)
	at org.eclipse.jdt.internal.core.JavaProject.setRawClasspath
(JavaProject.java:1975)
	at 
org.eclipse.pde.internal.ui.wizards.imports.UpdateClasspathOperation.run
(UpdateClasspathOperation.java:98)
	at 
org.eclipse.pde.internal.ui.wizards.imports.PluginImportOperation.createProject
(PluginImportOperation.java:265)
	at org.eclipse.pde.internal.ui.wizards.imports.PluginImportOperation.run
(PluginImportOperation.java:129)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java
(Compiled Code))
	at org.eclipse.pde.internal.ui.wizards.imports.PluginImportWizard$2.run
(PluginImportWizard.java:122)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run
(ModalContext.java:98)
Comment 1 Dejan Glozic CLA 2002-05-29 09:06:18 EDT
As you can see from the log, the exceptions are coming from JDT - PDE is just 
the messanger. 

BTW, from the path, I can tell you are using an old workspace because PDE does 
not allow binary projects without copying any more.
Comment 2 Philipe Mulet CLA 2002-05-29 12:45:44 EDT
We made the logging explicit in any case one is asking for the classpath of 
some project which is existing and opened but for which the .classpath file is 
missing.

I am suspecting PDE did silently remove the file and did not add it back (for 
some obscure reason?). We are currently investigating what is going on, early 
suspicion is that listeners of java model events are asking for refreshing 
while PDE is performing, and are asking questions they should not or which 
expose the fact that the .classpath file is missing.

Comment 3 Philipe Mulet CLA 2002-05-29 12:56:11 EDT
Clients of JDT/Core are guilty for causing the logging. Removing logging 
(unless in tracing mode). Note: we are still investigating in parallel to see 
if PDE import is causing us some grief.

Fixed
Comment 4 Dejan Glozic CLA 2002-05-29 13:00:14 EDT
I remember that this problem occured in the past when people did the following:

1) Place the workspace in location A
2) Run the build Bn by pointing to A
3) Import plug-ins from Bn as binary WITHOUT copying (meaning that projects 
were created as external and .classpath was written directly into 
eclipse/plugins/..)
4) After a while, when build Bn+1 arrived, they removed Bn and unzipped Bn+1 in 
the same place.
5) They started Bn+1 by pointing at workspace A. Since projects still point to 
the same location (Bn+1/eclipse/plugins/) but .classpath files are missing, JDT 
complains.

The solution for this problem was to unzip a new build in a new location and 
use Bn to import binary projects into workspace A by pointing at Bn+1. This 
way, new projects are created and .classpath is written into the tree. After 
this, Bn can be discarded and Bn+1 can be launched. The key is make a 
transition without starting the workspace A that points to the location now 
replaced with a new build.

The new PDE drivers do not allow binary import without copying, so this is not 
an issue any more.
Comment 5 Olivier Thomann CLA 2002-06-03 14:20:33 EDT
I have no idea how to verify this.
Comment 6 Philipe Mulet CLA 2002-06-04 04:57:52 EDT
Verified