Bug 5943

Summary: internal error in setting buildpath (name collsion)
Product: [Eclipse Project] JDT Reporter: Adam Kiezun <akiezun>
Component: CoreAssignee: Philipe Mulet <philippe_mulet>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P1    
Version: 2.0   
Target Milestone: 2.0 M1   
Hardware: PC   
OS: Windows 2000   
Whiteboard:

Description Adam Kiezun CLA 2001-11-15 05:21:23 EST 
1. in the org.eclipse.jdt.ui.tests plugin try addign the 
ui source folder of org.eclipse.jdt.ui project to the buildpath 
(open project properties)

2. you get:
4 org.eclipse.jdt.ui 1 Internal Error
Java Model Exception: Java Model Status [Name collision.]
	at org.eclipse.jdt.internal.core.JavaProject.setRawClasspath
(JavaProject.java:1753)
	at org.eclipse.jdt.internal.core.JavaProject.setRawClasspath
(JavaProject.java:1724)
	at 
org.eclipse.jdt.internal.ui.wizards.buildpaths.BuildPathsBlock.createJavaProject
(BuildPathsBlock.java:598)
	at 
org.eclipse.jdt.internal.ui.wizards.buildpaths.BuildPathsBlock.access$3
(BuildPathsBlock.java:556)
	at org.eclipse.jdt.internal.ui.wizards.buildpaths.BuildPathsBlock$2.run
(BuildPathsBlock.java:542)
	at org.eclipse.ui.actions.WorkspaceModifyDelegatingOperation.execute
(WorkspaceModifyDelegatingOperation.java:39)
	at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run
(WorkspaceModifyOperation.java:64)
	at org.eclipse.core.internal.resources.Workspace.run
(Workspace.java:1184)
	at org.eclipse.ui.actions.WorkspaceModifyOperation.run
(WorkspaceModifyOperation.java:78)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run
(ModalContext.java:98)
	4 org.eclipse.jdt.core 977 Name collision.
Comment 1 Martin Aeschlimann CLA 2001-11-19 12:11:15 EST 
Reproducable scenario:
1. project P1: source folder src
2. project P2: library folder P1/src, required project P1

Tolerated by JavaConventions.validateClasspath, rejected by setClasspath
Comment 2 Philipe Mulet CLA 2001-11-20 13:26:37 EST 
1. There is a classpath validation API: JavaConventions#validateClasspath

2. When using IJavaProject#setRawClasspath, it only performs a lightweight 
check of the new
   classpath, which however did catch a scenario missed by 
JavaConventions#validateClasspath.

   The offending scenario is a library folder nested inside a source folder. 
This should be
   forbidden, but the classpath validation did not find it.


The proposed change is:

a) Make the classpath validation code stricter (include a check for this 
scenario)
b) Have IJavaProject#setRawClasspath run the full classpath validation check 
before accepting
   the classpath update.

Any concern about this change ?
Comment 3 Philipe Mulet CLA 2001-11-21 07:43:54 EST 
Until getting more feedback, I left the #verifyClasspath in, and made the 
validation check stricter.
Comment 4 Philipe Mulet CLA 2001-11-22 11:08:06 EST 
Validation check is stricter and run whenever setting the classpath.
Fixed