Bug 23977 - .classpath corruption
Summary: .classpath corruption
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.0.1   Edit
Hardware: PC Windows 2000
: P2 normal (vote)
Target Milestone: 2.0.2   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-09-23 11:22 EDT by John P Cammarata CLA
Modified: 2002-10-31 03:25 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John P Cammarata CLA 2002-09-23 11:22:24 EDT
Environment Info: 
OS: Windows 2000 SP2. 
WSAD Build: 20020712_2002

Problem Description:  

The customer is using WSAD v5 beta and they observed that after adding Jar files 
using the "Java Jar Dependencies"  editor to add jar files to the .manifest file
that the project would fail to build.  The .log file revealed the 
stackTrace listed below:  

<stack trace>
!MESSAGE Problems occurred when invoking code from plug-in: 
"org.eclipse.core.resources".
!STACK 0
java.lang.ClassCastException: org.eclipse.core.internal.resources.File
       at 
org.eclipse.jdt.internal.core.JavaProject.computeExpandedClasspath(JavaProject.j
ava(Compiled Code))
       at 
org.eclipse.jdt.internal.core.builder.NameEnvironment.computeLocations(NameEnvir
onment.java(Compiled Code))
       at 
org.eclipse.jdt.internal.core.builder.NameEnvironment.computeLocations(NameEnvir
onment.java(Compiled Code))
       at 
org.eclipse.jdt.internal.core.builder.JavaBuilder.initializeBuilder(JavaBuilder.
java:417)
       at 
org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:90)
       at 
org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:392)
       at org.eclipse.core.runtime.Platform.run(Platform.java(Compiled Code))
       at org.eclipse.core.runtime.Platform.run(Platform.java(Compiled Code))
       at 
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:120)
       at 
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:176)
       at 
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:186)
       at 
org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:146)
       at org.eclipse.core.runtime.Platform.run(Platform.java(Compiled Code))
       at org.eclipse.core.runtime.Platform.run(Platform.java(Compiled Code))
       at 
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:160)
       at 
org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:211)
       at 
org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java(Compil
ed Code))
       at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1366)
       at 
org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.jav
a:78)
       at 
org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.jav
a:98)
!ENTRY org.eclipse.core.resources 4 2 Sep 10, 2002 11:02:58.387
</stack trace> 

Upon further investigation it appears that certain Jar files when added to the 
manifest file using the "Java Jar Dependencies" editor add the incorrect
 "kind" attribute in the .classpath file and this appears to cause the 
ClassCast Exception in the stack trace.  The customer's .classpath looked like 
the following after adding some jar files with the "Java Jar Dependency" editor: 

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
    <classpathentry kind="var" path="JRE_LIB" rootpath="JRE_SRCROOT" 
sourcepath="JRE_SRC"/>
    <classpathentry kind="lib" path="/EntApp/Utility.jar"/>
    <classpathentry exported="true" kind="src" path="/PersistenceEJB"/>
    <classpathentry exported="true" kind="src" path="/UtilityJava"/>
    <classpathentry kind="var" path="WAS_PLUGINDIR/lib/j2ee.jar"/>
    <classpathentry exported="true" kind="src" 
path="/EntApp/lib/xalan_v2.3.1/xercesImpl.jar"/>
    <classpathentry exported="true" kind="src" 
path="/EntApp/lib/xalan_v2.3.1/xml-apis.jar"/>
    <classpathentry kind="src" path="src"/>
    <classpathentry kind="output" path="bin"/>
</classpath>

Notice the xerces jar file has a kind attribute of 'src' instead of 'lib'.  
However, the other jar file that was 
added--Utility.Jar-- has a kind attribute of 'lib'.  If the customer changes the 
xercesImpl.jar file's kind attribute to 
'lib' instead of 'src' and does the same for all jar files and then the project 
builds OK with out a problem.  

We then tracked down the exact procedure he was doing. This problem seems to 
occur when you do the following in WSADv5:  

(TestCase)

* Open the Project Properties 
* Java Build Path -->Libraries Tab --> Add Jar file and click OK.  
* Project will rebuild. 
* Inspect .class path file.  Jar file will have the kind attribute of "lib". 

* Open  the Project Properties again
* Go to the "Java Jar Dependencies Page"
* Select the same file that you added to the build path above
* Click OK on Properties Page and Project will rebuild but the Properties window 
will NOT Close!! 
* Cancel out of the properties window and try to rebuild the project.  The 
rebuild fails with details of "org.eclipse.core.internal.resources.File. 
* Inspect the .classpath file you will see that the Jar file now has a kind 
attribute of 'src' instead of 'lib'. 
* If you change the kind attribute to "lib" in the .classpath file then 
everything works OK.
Comment 1 Philipe Mulet CLA 2002-09-24 05:34:52 EDT
First time I've seen this behavior. Need to investigate asap.
Comment 2 Philipe Mulet CLA 2002-09-24 05:36:31 EDT
Sounds like an error scenario which we do not recover nicely from. I am also 
wondering about how we got into this state (WSAD bug?).
Comment 3 Philipe Mulet CLA 2002-09-24 09:37:35 EDT
Fixed in latest integration build.
Comment 4 David Audel CLA 2002-10-17 10:03:16 EDT
Verified.
Comment 5 Philipe Mulet CLA 2002-10-21 18:00:20 EDT
Backported to 2.0.2
Comment 6 David Audel CLA 2002-10-31 03:25:12 EST
Verified in 2.0.2.