RE: [platform-vcm-dev] Move Delete Hooks problem

["Clemm, Geoff" <gclemm@xxxxxxxxxxxx>]

   From: Balaji Krishnamachari-samp [mailto:balajik@xxxxxxxxxx]

   I am working on move delete hooks for a repository provider
   plug-in. It seems like the navigator view and the package explorer
   view handle moving resources differently.

   Let us assume my package structure is defined as the following: 

   Navigator View: 
   + src 
     + com 
	  + ibm 
	      + package1 
			Test1.java 
			Test2.java 
			+ innerPackage 
				 Test3.java   

   Package Explorer View: 
   + src 
	 + com.ibm.package1 
		  Test1.java 
		  Test2.java 
	 + com.ibm.package1.innerPackage 
		   Test3.java   

   If I try to rename the folder package1 inside navigator view, a
   moveFolder is called on package1 which seems to make sense.

That is correct behavior.

   But if we try to rename the package package1 to package2 in package
   explorer, the jdt does a real good job of calling the
   moveFile(Test1.java) and moveFile(Test2.java) rather than renaming
   outer and inner package com.ibm.package1.innerPackge. ( This seems
   to make sense because jdt does not want to rename all the inner
   package structures).

I don't understand your comment that "this seems to make sense".  In
particular, if the move is successful, how can the jdt not rename all
the inner package structures?  The only logically correct behavior
here would be for the package explorer to act the same as the
navigator, i.e.  first call a moveFolder of package1 to package2
(where moveFolder can cancel the request).  If this is not cancelled
by the moveFolder hook, then all the implied changes should be
performed invoking "side-effect" notifications that cannot cancel the
operation (a hook should not be allowed to cancel "part" of the
package1 to package2 move).  In particular, once the move
operationhas begun, a cancel would have
to have a way of "undo"ing any partially completed parts of the
move, including "undo"ing the results of any hooks it has called,
which is not feasible since there are no "undo" actions defined
for hooks.

   To acomplish the above mentioned scenario, jdt does the following: 
   1. Create a package com.ibm.package2 

This should not have been done until the moveFolder(package1, package2)
hook had been called.

   2. Move the filesTest1.java and Test2.java from package1 to package2. 

This should not have been done until the moveFolder(package1, package2)
hook had been called.  And any hooks invoked by these finer grained
operations should be "notifications", i.e. not allowed to be canceled
by the user.

   3. Since the move did not happen in the repository, being a
      pessimistic provider, I cancel the local move operation after
      getting the users input on the cancel operation. User had
      requested to cancel the operation and hence I set the status to
      IStatus.OK.

Giving your hooks an option to cancel at this point would be an error,
since there is no "undo hook" support defined for previously
invoked hooks.

   4. Since the source package com.ibm.package1 is not empty, jdt
      tries to delete the file Test1.java and Test2.java from
      com.ibm.package1. ( Interestingly jdt does not check whether the
      move operation was successful or not... Does it mean I need to
      set the status to ERROR or error rather than OK to make jdt
      realize that move delete hooks were called but the move did not
      happen ( setting it to INFO does not change the
      behavior. setting it to ERROR will abort the operation which I
      don't need. I want to provide users with an option to rename all
      the files under the package in the repository and if successful
      want to mirror the operation locally) ).

Yes, if the moveFolder hook had correctly been invoked by the
package explorer, you would have been given this option to abort
the request.

   Should the jdt not check the return codes ( or at least the
   existense of the resource in source package ) and do the operations
   appropriately. if I cancel my individual renames of all files and
   the deletes on all the files, I get a internal error exception
   "Resource Test1.java not found in package com.ibm.package2". The
   package com.ibm.package2 is not deleted too after the operation is
   completed.

Once the move has been started, the package explorer should not give
you an option to cancel actions that are implied by the move.

Cheers,
Geoff