Ramosa, We have actually discussed this in the past. Arnout made a suggestion about rationalising the whole move/delete/copy operations. I have appended the resulting discussion below. The direction is clear - we should deprecate/remove deltree and extend delete to cover the deletion of a directory tree.
Here is our previous discussion: > > One question, will you retain deltree? If not, how do you distinguish > > between deleting the contents of the directory and deleting > > the directory > > AND its contents? > > deltree should not be retained because of duplication. The new delete > task also covers the current deltree funtionality (see case 1 below). > > The proposal for the new delete task includes the functionality of > the current deltree and delete tasks, and extends it with recursing > through a directory, to be able to remove only files that match a > pattern. This way, the basic file operations (copy, delete, and move) > work more or less the same. > > > We can distinguish between the two cases mentioned before: > > <delete dir="somedirectory"/> > > without includes and excludes will delete the directory AND contents > (makes sense, if you want to delete the directory, you want to include > all its content). > > <delete dir="somedirectory" includes="..." excludes="..."/> > > (thus with includes and/or excludes) will delete the contents of the > directory, but not the directory itself (makes also sense, if you want > to include and exclude files from deleting, you don't want the > directory itself to be removed). > > To the last case, an attribute can be added to allow the directory to > be deleted when it is empty (e.g. deletewhenempty="true"). But I think > that this will not be used very often. > > Cheers, > > Arnout > -- Conor MacNeill Home: [EMAIL PROTECTED] Work: [EMAIL PROTECTED] Web: www.cortexebusiness.com.au
