On 2010-05-07, Bruce Atherton <br...@callenish.com> wrote: > On 07/05/2010 7:52 AM, Stefan Bodewig wrote:
> I'm a big fan of a little consistency. you won't like what I'm going to say 8-) >> I see several options: >> (2) Add a new attribute that controls whether read-only files should be >> overwritten (let's rely on File.canWrite). >> What should be its default value? What would be its name? > This is the only sensible option IMO. I like your idea of "force". That's what I implemented - and I did so at the ResourceUtils#copyResource level so anything that uses that method to copy to a potentially read-only destination file is going to be affected. Then I scanned the sources to see which other tasks use this method (or FileUtils' copyFile) to see whether I feel they should be adapted. The following non-deprecated tasks use copyFile or copyResource as well: <move>, the WebLogic deployment tool, <netrexxc>, <rmic>. <concat> and <echo>. For most of them I'd be willing to accept the backwards incompatibility and just have the tasks throw exceptions if they cannot write to the destination files. The main exception to me would be <move> and <concat>. <move> will try to perform a rename which falls back to delete if File#rename fails - so in general it will replace read-only files. To be consitent it should either check whether the destination is read-only before trying to rename as well, or it should always overwrite existing files in copy mode. I tend to perform the check before renaming and am not sure what the default should be. <concat> already defines an attribute named force - and it does just what the attibute named overwrite does for <copy>. Does anybody have a good idea for an attribute name that says "overwrite read-only destination files" and can be used in both <copy> and <concat>? Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
