The provided filter operation:

    filter { String line ->
        "[$line]"
    }

can be useful when you want to perform an independent operation for each input line. However, I think that in well over 90% of real life uses, people use that line-by-line transformer as an inefficient substitute when what is really needed is a transformer for the entire contents of the file. For example, say somebody has a 1,000 line text file and wants to perform substitutions without expand's TemplateEngine rules/overhead/limitations or Ant's 1-character-delimiter constraints. They would use the construct above to perform 1000 substitution operations when what is really desired is a single substitution operation on the entire file content. This allows for efficient and powerful operations using repetitive java.util.regex.Matcher region operations, Groovy or third party XML transformers, etc., as well as substitutions that incorporate or span line delimiters.

If it is being done line-by-line to avoid loading too much file content into RAM, that is a poor solution that is dependent upon existence of line delimiters. XML written by some libraries does not contain line breaks by default. If a buffering size constraint is desired, that should be implemented explicitly in a safe and reliable way.

I am attaching working solution. It's a Goovy implementation of FilterReader that works like so:

    copy {
        from 'addl'
        into 'cpdest'
        filter(com.admc.gradle.ContentAsStringFilter, closure: {
            return it.toUpperCase()
        })
    }

I, for one, would like this capability in Gradle core. It's very likely that this could be implemented much more elegantly (than my attached class) by someone with the power to expand the Gradle DSL.