Community
Participate
Working Groups
I'm seeing the following delta merge trace during execution of a new project wizard and, although it is probably the intended behavior, it is not what I had been expecting: Use case: a project is created and then the cp is modified - all of this is being executed within a workspace runnable w/ the workspace root as the scheduling rule and AVOID_UPDATE set as the flag. Expected behavior: the ADDED delta for the project would be delivered as a separate event from the various CHANGED deltas Actual behavior: the ADDED and CHANGED deltas for the project are getting merged together and what is returned is an added delta for the project: Java Model[*]: {CHILDREN | CONTENT} Util3[+]: {} ResourceDelta(/Util3)[*] Question: should the added delta be getting merged with the changed deltas? (I have an IElementChangedListener that is responding to classpath modifications and it is missing these events due to this merge handling). -------------------- MERGING 9 DELTAS [Thread[Main Thread,6,main]] Java Model[*]: {CHILDREN} Util3[*]: {CHILDREN | CLASSPATH CHANGED} <project root>[*]: {REMOVED FROM CLASSPATH} src[*]: {ADDED TO CLASSPATH} Java Model[*]: {CHILDREN} Util3[*]: {CHILDREN | CLASSPATH CHANGED} C:\BEA\dev\src910\build\jrockit-jdk1.5.0_04\jre\lib\managementapi.jar[*]: {ADDED TO CLASSPATH} C:\BEA\dev\src910\build\jrockit-jdk1.5.0_04\jre\lib\rt.jar[*]: {ADDED TO CLASSPATH} C:\BEA\dev\src910\build\jrockit-jdk1.5.0_04\jre\lib\jsse.jar[*]: {ADDED TO CLASSPATH} C:\BEA\dev\src910\build\jrockit-jdk1.5.0_04\jre\lib\jce.jar[*]: {ADDED TO CLASSPATH} C:\BEA\dev\src910\build\jrockit-jdk1.5.0_04\jre\lib\charsets.jar[*]: {ADDED TO CLASSPATH} C:\BEA\dev\src910\build\jrockit-jdk1.5.0_04\jre\lib\ext\dnsns.jar[*]: {ADDED TO CLASSPATH} C:\BEA\dev\src910\build\jrockit-jdk1.5.0_04\jre\lib\ext\localedata.jar[*]: {ADDED TO CLASSPATH} C:\BEA\dev\src910\build\jrockit-jdk1.5.0_04\jre\lib\ext\sunjce_provider.jar[*]: {ADDED TO CLASSPATH} C:\BEA\dev\src910\build\jrockit-jdk1.5.0_04\jre\lib\ext\sunpkcs11.jar[*]: {ADDED TO CLASSPATH} Java Model[*]: {CHILDREN} Util3[*]: {CLASSPATH CHANGED} Java Model[*]: {CHILDREN} Util3[*]: {CHILDREN | CLASSPATH CHANGED} C:\BEA\src910_15004jr\bea\weblogic92\server\lib\api.jar[*]: {ADDED TO CLASSPATH} C:\BEA\src910_15004jr\bea\weblogic92\server\lib\weblogic.jar[*]: {ADDED TO CLASSPATH} Java Model[*]: {CHILDREN} Util3[*]: {CHILDREN | CLASSPATH CHANGED} C:\BEA\workspaces\runtime-workspace\.metadata\.plugins\com.bea.wlw.libmodules.core\beehive-controls-1.0_1.0_1.0\APP-INF\lib\beehive-controls.jar[*]: {ADDED TO CLASSPATH} C:\BEA\workspaces\runtime-workspace\.metadata\.plugins\com.bea.wlw.libmodules.core\beehive-controls-1.0_1.0_1.0\APP-INF\lib\beehive-ejb-control.jar[*]: {ADDED TO CLASSPATH} C:\BEA\workspaces\runtime-workspace\.metadata\.plugins\com.bea.wlw.libmodules.core\beehive-controls-1.0_1.0_1.0\APP-INF\lib\beehive-jdbc-control.jar[*]: {ADDED TO CLASSPATH} C:\BEA\workspaces\runtime-workspace\.metadata\.plugins\com.bea.wlw.libmodules.core\beehive-controls-1.0_1.0_1.0\APP-INF\lib\beehive-jms-control.jar[*]: {ADDED TO CLASSPATH} C:\BEA\workspaces\runtime-workspace\.metadata\.plugins\com.bea.wlw.libmodules.core\beehive-controls-1.0_1.0_1.0\APP-INF\lib\commons-codec-1.3.jar[*]: {ADDED TO CLASSPATH} C:\BEA\workspaces\runtime-workspace\.metadata\.plugins\com.bea.wlw.libmodules.core\beehive-controls-1.0_1.0_1.0\APP-INF\lib\commons-discovery-0.2.jar[*]: {ADDED TO CLASSPATH} C:\BEA\workspaces\runtime-workspace\.metadata\.plugins\com.bea.wlw.libmodules.core\beehive-controls-1.0_1.0_1.0\APP-INF\lib\commons-logging-1.0.4.jar[*]: {ADDED TO CLASSPATH} C:\BEA\workspaces\runtime-workspace\.metadata\.plugins\com.bea.wlw.libmodules.core\beehive-controls-1.0_1.0_1.0\APP-INF\lib\log4j-1.2.8.jar[*]: {ADDED TO CLASSPATH} Java Model[*]: {CHILDREN} Util3[*]: {CHILDREN | CLASSPATH CHANGED} C:\BEA\workspaces\runtime-workspace\.metadata\.plugins\com.bea.wlw.libmodules.core\weblogic-controls-1.0_1.0_1.0\APP-INF\lib\weblogic-controls.jar[*]: {ADDED TO CLASSPATH} C:\BEA\workspaces\runtime-workspace\.metadata\.plugins\com.bea.wlw.libmodules.core\weblogic-controls-1.0_1.0_1.0\APP-INF\lib\weblogic-webservice-control.jar[*]: {ADDED TO CLASSPATH} C:\BEA\workspaces\runtime-workspace\.metadata\.plugins\com.bea.wlw.libmodules.core\weblogic-controls-1.0_1.0_1.0\APP-INF\lib\wlcommons-logging.jar[*]: {ADDED TO CLASSPATH} C:\BEA\workspaces\runtime-workspace\.metadata\.plugins\com.bea.wlw.libmodules.core\weblogic-controls-1.0_1.0_1.0\weblogic-timer-control.jar[*]: {ADDED TO CLASSPATH} C:\BEA\workspaces\runtime-workspace\.metadata\.plugins\com.bea.wlw.libmodules.core\weblogic-controls-1.0_1.0_1.0\weblogic-messagebuffer-mdb.jar[*]: {ADDED TO CLASSPATH} Java Model[*]: {CHILDREN} Util3[*]: {CHILDREN | CLASSPATH CHANGED} C:\BEA\src_15004jr\bea\weblogic92\server\lib\apache_xbean.jar[*]: {ADDED TO CLASSPATH} Java Model[*]: {CHILDREN} Util3[*]: {CHILDREN | CLASSPATH CHANGED} build/xbean/bin[*]: {ADDED TO CLASSPATH} build/xbean/.src[*]: {ADDED TO CLASSPATH} Java Model[*]: {CHILDREN | CONTENT} Util3[+]: {} ResourceDelta(/Util3)[*] FIRING POST_CHANGE Delta [Thread[Main Thread,6,main]]: Java Model[*]: {CHILDREN | CONTENT} Util3[+]: {} ResourceDelta(/Util3)[*] Listener #1=com.bea.wlw.controls.core.discovery.ControlsCache@249076 -> 0ms Listener #2=org.eclipse.jem.internal.adapters.jdom.JavaReflectionSynchronizer@6c1012 -> 0ms Listener #3=org.eclipse.jem.internal.adapters.jdom.JavaReflectionSynchronizer@6c0ff4 -> 0ms Listener #4=org.eclipse.jem.internal.adapters.jdom.JavaReflectionSynchronizer@6c0fd6 -> 0ms Listener #5=org.eclipse.jem.internal.adapters.jdom.JavaReflectionSynchronizer@6c0fb8 -> 0ms Listener #6=org.eclipse.jem.internal.adapters.jdom.JavaReflectionSynchronizer@6c0d37 -> 0ms Listener #7=org.eclipse.jst.j2ee.refactor.listeners.J2EEElementChangedListener@7c9e6eJ2EEElementChangedListener.elementChanged(org.eclipse.jdt.core.ElementChangedEvent[source=Java Model[*]: {CHILDREN | CONTENT} Util3[+]: {} ResourceDelta(/Util3)[*]]) -> 0ms Listener #8=org.eclipse.jdt.apt.core.internal.generatedfile.ElementChangedListener@8801bf -> 0ms Listener #9=org.eclipse.jem.internal.adapters.jdom.JavaReflectionSynchronizer@a422d5 -> 0ms FIRING POST_RECONCILE Delta [Thread[Main Thread,6,main]]: <NONE>
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.
