Community
Participate
Working Groups
I20040511 1. create a library called SWT, add the swt.jar into it 2. create a project, add the SWT library to the build path 3. expand the project in the package explorer, look at the library, the JAR (swt.jar) in it and the content of the JAR 4. select swt.jar, open properties (context menu), set a source attachment (doesn't matter what, e.g. take itself swt.jar), press ok -> the package explorer get updated, source attachment adornment is now visible on JAR image 5. again select swt.jar, open properties and clear the source attachment repeat steps 4. and 5. and observe the package explorer: suddedly the package explorer doesn't show the JAR contents anymore 5. double click the SWT library in the package explorer. Suddly the contents are back in the state wher the JAR has no children, I debugged and found that no classpath entry was found for the package fragment root element. The classpath in that state only consisted of the JRE library.
*** Bug 61850 has been marked as a duplicate of this bug. ***
looking at the java element deltas, for each configuration you get 2 deltas Java Model[*]: {CHILDREN} zz[*]: {CHILDREN} C:/devel/sdk40428/eclipse/plugins/org.eclipse.swt.win32_3.0.0/ws/win32/ swt.jar[*]: {REMOVED FROM CLASSPATH} Java Model[*]: {CHILDREN} zz[*]: {CHILDREN} C:/devel/sdk40428/eclipse/plugins/org.eclipse.swt.win32_3.0.0/ws/win32/ swt.jar[*]: {ADDED TO CLASSPATH} When the problem happens, you only get the remove (the reason that the JAR element isn't removed from the view could be a package exlorer problem, have to investigate)
Package explorer refresh issue is likely a consequence of bug 62120. So the fix for this bug is only a workaround; but still a good improvement.
Fixed. Previously, when modifying source attachement path for a user library, classpath entry was in fact removed and new value was added to .classpath file. Unfortunately, in some cases, event of .classpath refresh (bug 62120) happen too late and user library displayed in package explorer became insconsistent. To avoid this problem, we just set classpath with a new user library classpath container with same user library name. Then, setting classpath container just recompute the user library content without removing/adding it. [jdt-core-internal] Change made in method rebindClasspathEntries(String,boolean,IProgressMonitor) of UserLibraryManager class. Test case added in ClasspathInitializerTests
Verified in 200405180816
