Kev Jackson wrote: > >> In that case I would like some time to think things over, as to >> provide one face, and to have different implementations for currently >> different parts. >> Classes that support copying, things that support permissions, things >> that support path manipulation, without getting a really big number >> of classes. >> >> FileUtils for Java 1.6 on Windows >> FileUtils for Java 1.4 on VMS >> etc. >> >> I had an idea to turn FileUtils into a Facade that delegates >> different actions to different back-ends. >> > I think I can see where you are going with this, and it's definitely > an alternative to what I thought to begin with and the direction I was > heading in the code. I'm viewing the cleanest split as using an > interface, from your perspective you think a master FileUtils (class > not interface) that delegates all the real work to a specialization > class. I think that your view would provide the quickest benefit - ie > it would be more easily added to the entire codebase (as there would > be no need to remove references to FileUtils from all the tasks). > > Thanks for your thoughts > Kev > Hi, in this case, what we could do would be to create a new package org.apache.tools.ant.util.java14 (this is OK for bootstrapping and build.xml) and create there a class NIOUtils or something like that with some static methods, including simply one method which copies one file to the other.
If anyway ResourceUtils does the work now, ResourceUtils could test whether running under Java 1.4 or more and call NIOUtils to do the work happening between lines 364 to 379 of ResourceUtils (copying files with no filters, no bells and whistles). Regards, Antoine --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
