Summary: | [model] Delta merge behavior | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Rob Frost <rfrost> |
Component: | Core | Assignee: | Jerome Lanneluc <jerome_lanneluc> |
Status: | RESOLVED WONTFIX | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | jgarms, konstantin |
Version: | 3.1.1 | ||
Target Milestone: | 3.3 RC4 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Rob Frost
2005-12-19 11:17:31 EST
Here is a slightly different merge case that's unexpected and causing me problems: the deletion of a folder and the removal of the CP element for that folder are being merged and the CP removal is being masked by the folder deletion (look at the deltas for "build/xbean/bin" and "build/xbean/.src"); note: I had included logic at one point to handle the kind=REMOVED for the folder if the flag for the project was F_CLASSPATH_CHANGED, however, I was seeing deltas w/ those values when folder had been deleted and the corresponding CP element not removed - seems like this type of merge and the corresponding one for the add case are potentially problematic. ... MERGING 2 DELTAS [Thread[Main Thread,6,main]] Java Model[*]: {CHILDREN} Util[*]: {CHILDREN | CLASSPATH CHANGED} build/xbean/bin[*]: {REMOVED FROM CLASSPATH} build/xbean/.src[*]: {REMOVED FROM CLASSPATH} C:\BEA\dev\src\build\jrockit-jdk1.5.0_04\jre\lib\managementapi.jar[*]: {REORDERED} C:\BEA\dev\src\build\jrockit-jdk1.5.0_04\jre\lib\rt.jar[*]: {REORDERED} C:\BEA\dev\src\build\jrockit-jdk1.5.0_04\jre\lib\jsse.jar[*]: {REORDERED} C:\BEA\dev\src\build\jrockit-jdk1.5.0_04\jre\lib\jce.jar[*]: {REORDERED} C:\BEA\dev\src\build\jrockit-jdk1.5.0_04\jre\lib\charsets.jar[*]: {REORDERED} C:\BEA\dev\src\build\jrockit-jdk1.5.0_04\jre\lib\ext\dnsns.jar[*]: {REORDERED} C:\BEA\dev\src\build\jrockit-jdk1.5.0_04\jre\lib\ext\localedata.jar[*]: {REORDERED} C:\BEA\dev\src\build\jrockit-jdk1.5.0_04\jre\lib\ext\sunjce_provider.jar[*]: {REORDERED} C:\BEA\dev\src\build\jrockit-jdk1.5.0_04\jre\lib\ext\sunpkcs11.jar[*]: {REORDERED} C:\BEA\src_15004jr\bea\weblogic92\server\lib\api.jar[*]: {REORDERED} C:\BEA\src_15004jr\bea\weblogic92\server\lib\weblogic.jar[*]: {REORDERED} Java Model[*]: {CHILDREN} Util[*]: {CHILDREN | CONTENT} build/xbean/.src[-]: {} build/xbean/bin[-]: {} ResourceDelta(/Util/.classpath)[*] ResourceDelta(/Util/.project)[*] ResourceDelta(/Util/.settings)[*] ResourceDelta(/Util/build)[*] FIRING POST_CHANGE Delta [Thread[Main Thread,6,main]]: Java Model[*]: {CHILDREN} Util[*]: {CHILDREN | CLASSPATH CHANGED} build/xbean/bin[-]: {} build/xbean/.src[-]: {} C:\BEA\dev\src\build\jrockit-jdk1.5.0_04\jre\lib\managementapi.jar[*]: {REORDERED} C:\BEA\dev\src\build\jrockit-jdk1.5.0_04\jre\lib\rt.jar[*]: {REORDERED} C:\BEA\dev\src\build\jrockit-jdk1.5.0_04\jre\lib\jsse.jar[*]: {REORDERED} C:\BEA\dev\src\build\jrockit-jdk1.5.0_04\jre\lib\jce.jar[*]: {REORDERED} C:\BEA\dev\src\build\jrockit-jdk1.5.0_04\jre\lib\charsets.jar[*]: {REORDERED} C:\BEA\dev\src\build\jrockit-jdk1.5.0_04\jre\lib\ext\dnsns.jar[*]: {REORDERED} C:\BEA\dev\src\build\jrockit-jdk1.5.0_04\jre\lib\ext\localedata.jar[*]: {REORDERED} C:\BEA\dev\src\build\jrockit-jdk1.5.0_04\jre\lib\ext\sunjce_provider.jar[*]: {REORDERED} C:\BEA\dev\src\build\jrockit-jdk1.5.0_04\jre\lib\ext\sunpkcs11.jar[*]: {REORDERED} C:\BEA\src_15004jr\bea\weblogic92\server\lib\api.jar[*]: {REORDERED} C:\BEA\src_15004jr\bea\weblogic92\server\lib\weblogic.jar[*]: {REORDERED} ResourceDelta(/Util/.classpath)[*] ResourceDelta(/Util/.project)[*] ResourceDelta(/Util/.settings)[*] ResourceDelta(/Util/build)[*] ... Hi Jerome, Just wanted to check and see if you've had a chance to take an initial look at this one yet. thanks, Rob For scenario in comment 0, the merge is expected as you suspected. The rational being that before the workspace runnable starts would not see the project, and after the worspace runnable has finished, the client would see a new project, thus the ADDED delta. The fact that the project was added in 2 steps should not be relevant to the client. If it was added in one step with the right classpath, this should be equivalent to the client. For scenario in comment 1, what delta would you expect ? Thanks for taking a look; the merge in case 0 makes sense; regarding #1, I had been expecting that these deltas would not be merged (i.e. the content change and the cp change would be kept distinct) The delta indicates how the Java model is changed, not how the resources on disk are changed. So an IPackageFragmentRoot deletion indicates that this package fragment root is no longer present in the model. This works as designed. No action planned. |