On Wed, Oct 28, 2009 at 9:31 PM, Adam Murdoch <[email protected]> wrote:
<snip>
This method might look something like:
>
> eachFile { FileCopyDetails details ->
>
> if (not a special file) {
> return
> }
>
> perform phase one renaming
> perform phase two renaming
>
> if (resultName is not valid) {
> details.exclude()
> }
> else {
> details.setPath(resultName)
> }
> }
>
> FileCopyDetails would extend FileVisitDetails and add methods to allow you
> to:
> - exclude the file from the result
> - set the destination name or the path for the file
> - set the filter to use when reading or writing to the file
>
>
That sounds like a good solution to me. Especially since we are needing to
filter as well in our current use-case. We are doing that by having two
different froms in the copySpec. Both has the same remapTarget closure, but
one excludes files that we need to filter and the other includes files we
need to filter and sets up a filter. Like this:
copy.from(fromDir) {
filteredFiles.each { exclude it }
remapTarget remapClosure
}
copy.from(fromDir) {
filteredFiles.each { include it }
remapTarget remapClosure
filter(ReplaceTokens, tokens:replacedTokens)
}
This is because filtering binary files often corrupts them, so we only
wanted to filter some of the files. We didn't like this way is it requires
the copy to make two passes through the from directory, however. Your idea
will allow us to do this in one pass, and it's nice and explicit. I like
it. I guess this is a case of "state your problem, not your solution".
Sorry about that.
--
John Murph
Automated Logic Research Team
