Martijn Kruithof wrote:
Hi,
Adding setting the property using -D to ANT_OPTS should do.
5 things:
1) I saw you removed public members (constants) from FileUtils (Non
backward compatible change, keeping everything BC also frustrates me
sometimes, but still I think it is best not to break parts we do not
know of.)
Yes that was a mistake, I thought that they'd be available from the
interface, but realised after I sent the email that only Copy is using
the interface and all other tasks are still tied to the implementation.
I need to put this back in the default impl to retain bwc as you mentioned.
2) If the FileUtilsFactory is called from or implemented in
FileUtils.getFileUtils() / FileUtils.newFileUtils(), every task is
going to benefit.
I think the implementation I provided does precisely this, or rather it
calls from the interface (FileUtilsAdapter) instead of from the
implementation. If you mean that the current FileUtils should delegate
to another implementation using the factory that's different.
I think it would be cleaner to gradually transition all the tasks over
to an interface (while retaining the FileUtils semi-singleton). At the
point where all the tasks are using FileUtilsAdapter, we can refactor
and remove the parts of FileUtils that are exposed correctly in the
interface, maintaining bwc that way - the only thing left would be a
small stub which contains the static methods - that's my view of how a
transition would work anyway.
I think that using FileUtils to delegate/proxy to a real class would be
less 'elegant' than using an interface - although I can see the
immediate advantages of using the approach you mentioned (all tasks
benefit without actually having to change each class over to the interface).
3) Again / Still the actual copying has been moved to the
ResourceUtils, how do we make sure that files addressed as resources
also benefit from this change.
I'm not sure what you mean by this - the code is proof of concept to
show that it would be possible to add in nio based file handling in a
way that minimizes problems of bwc. I didn't attempt to add nio for
handling resources - indeed that would mean changing the ResourceUtils
class, which I didn't want to do as it would have been a big waste of
time if the overall strategy was wrong. Right now I just want to play
with some basic ideas and see if people here on dev list thing that the
strategy is good/hopelessly broken/not worth pursuing
The intention isn't to be a complete solution to all resource handling,
just to be complete enough to provide a background for further
discussion - I fully expect most of the code to be thrown away, but
without something that executes it's hard to see the potential flaws.
Regarding the changes in the Copy task:
4) Stringbuffer is not more efficient than concatenation using + in a
single statement.
[snip]
Sorry this was change that I didn't roll-back from earlier, it shouldn't
be there
5) StringBuffer handling is incorrect for the second part, (you will
concatenate all to filenames.)
again please dis-regard this part of the code as it isn't meant to be there
This shows what happens when you have several different ideas being
worked on at the same time and you create a unified diff without
looking! (my bad)
Thanks for the comments
Kev
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
