Community
Participate
Working Groups
smoke for I20040907 1) Create project JUnit 2) Import JUnit zip into the JUnit project 3) Create source folder src 4) In package explorer: drag'n drop folder junit into src 5) Ctrl+T, type Test -> there are more than one location for type test 6) ENTER -> Error dialog: Could not uniquely map the type name to a type...
Problem exists in 3.0 as well.
Types are still doubled even if I shutdown and restart Eclipse which repopulates the all types cache. So this seems to be a search problem.
Closing and reopening the project brings everything back in sync
Adding the source folder creates the following delta org.eclipse.jdt.core.ElementChangedEvent[source=Java Model[*]: {CHILDREN} JUnit[*]: {CHILDREN | CLASSPATH CHANGED} <project root>[*]: {REMOVED FROM CLASSPATH} src[+]: {} ResourceDelta(/JUnit/junit/samples/money)[*] ResourceDelta(/JUnit/junit/tests/extensions)[*] ResourceDelta(/JUnit/junit/tests/framework)[*] ResourceDelta(/JUnit/junit/tests/runner)[*] ResourceDelta(/JUnit/.classpath)[*] ResourceDelta(/JUnit/junit)[*]] which the all types cache correctly interprets and as a result flushes the all types cache.
The all type search (SearchEngine#searchAllTypeNames()) triggered by this delta still returns JUnit classes (for example /JUnit/junit/framework/Test.java) although the projects root is now longer on the class path (the package explorer renders the project correctly).
Moving to JDT/Core. Looks like the the index dealing with all types names doesn't get updated correctly on classpath changes.
Can you clarify step 2? Do you mean you imported the jar file into the project, AND then you added it to the classpath?
This is the import of source files from JUnit zip file located in: <install_dir>\eclipse\plugins\org.eclipse.jdt.source_3.1.0\src\org.junit_3.8.1\junitsrc.zip You haven't to change anything in project build path at this step...
Frederic is corrrect (we use File->Import->Zip File). I can mail you the zip file we are using if you need it.
After step 3, the junit folder is no longer on the classpath, but all of its types are still available. We should have treated this as if they were deleted... just as the builder did (notice all of the warnings went away).
Jerome: It looks like the delta processor needs to detect the .classpath change when the project is removed as a source folder & the recently created 'src' folder takes over. As it stands now, a delta is propagated when the 'src' folder is created. But at that point it is considered as a package fragment inside the project (which is currently the source folder). We need to notify the IndexManager that the project is no longer the source folder & then add the 'src' folder as the new source folder.
To better reflect the problem, changing the summary from "Deltas are incomplete after adding a source folder" to "Index not updated after adding a source folder"
SetClasspathOperation#updateAffectedProjects(...) removes all project post actions. As a consequence it removes the post action that delete the files in the project source folder from the index. These files remain in the index. Changed SetClasspathOperation#updateAffectedProjects(...) to remove the "UpdateClasspath" post actions only. Added regression test SearchTests#testChangeClasspath2()
Verified for 3.1 M2 with build I200409230010.
