I was trying to keep the way copy, delete, and move worked consistent so I figured either they all have an implicit fileset or none of them do. The consensus (sp?) way back when was to _not_ have an implicit fileset, so I went with that. Should we make all three have the implicit fileset? So we get
<copy dir="blah" todir="otherblah" includes="*.html">
<include name="**/*.css" />
<exclude name="**/*.htm" />
<fileset dir="yet_another_blah">
<include name="**/yadda_yadda.*" />
</fileset>
</copy>
I was trying to stay away from this, because it looks a bit sloppy to me. That being said, I'm happy to temporarily use the implicit fileset for delete to maintain current functionality, and remove it after the next release.
The copy task does have the flatten attribute. In point of fact, so does the move task. Move inherits from copy, the only difference is that once the copy is complete, move deletes the original file. Oh, and to overwrite existing files is the default. So, we get all the same features, including flattening, filtering, and overwrite.
The delete task using the dir attribute does actually delete the directory. I didn't make that explicit in the examples, as I figured that most people would assume that's the default behaviour. I called it out in move because there is the chance someone would assume that the files under the directory are to be moved, not the directory itself.
To delete empty directories when using filesets in the delete task, I could walk the tree of included directories and attempt to delete them. However, this behaviour might best be triggered with an attribute (<delete removeEmpty="yes" ...>) because I seem to recall people wanting to delete all the files in a directory tree, but keep the tree around.
Glenn McAllister
Software Developer. IBM Toronto Lab, (416) 448-3805
"An approximate answer to the right question is better than the
right answer to the wrong question." - John W. Tukey
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: Re: [PATCH] Consolidated copy, move, and delete tasks
>>>>> "gm" == glennm <[EMAIL PROTECTED]> writes:
gm> The biggest difference between these tasks and the current
gm> delete, deltree, copyfile, and copydir tasks is that the fileset
gm> is _not_ implicit. The drawback to this is that it breakes
gm> existing delete functionality. The advantage is clarity and
gm> consistency in the use of filesets.
Any chance to temporarily keep the old behavior within <delete>
(i.e. add an implicit fileset to <delete> and only to <delete>)?
I have no problem removing deprecated things - nothing that has been
deprecated in Ant 1.1 is still present. But if possible we should keep
build files, that were perfectly well adapted to Ant 1.1, working.
I'd propose to add an implicit fileset to delete, emit deprecation
warnings if it is used and remove it right after the next release.
gm> I'm affraid I deleted the email where Conor explained how to
gm> include new files in a patch,
Trick CVS into thinking the file has been added (i.e. add an entry for
each file to the corresponding CVS/Entries file).
gm> Copy
Let's keep the flatten attribute. At least one guy out there seems to
need it 8^).
gm> Move [...]
gm> Note that the above move will actually remove the "directory"
gm> subdirectory of "original".
Is it consistent for <move> to remove (empty) directories but <delete>
to keep them?
Stefan
- who hasn't found time to actually read your code yet.
