Summary: | library looses content when setting source attachment | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Martin Aeschlimann <martinae> |
Component: | Core | Assignee: | Frederic Fusier <frederic_fusier> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | major | ||
Priority: | P3 | CC: | kirill_frolov |
Version: | 3.0 | ||
Target Milestone: | 3.0 M9 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Martin Aeschlimann
2004-05-12 05:49:12 EDT
*** 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 |