[GRADLE-1980] Provide a copy filter where closure transforms entire file text content Created: 02/Dec/11  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 1.0-milestone-6
Fix Version/s: None

Type: New Feature
Reporter: Blaine Simpson Assignee: Unassigned
Resolution: Won't Fix Votes: 0

Attachments: File ContentAsStringFilter.groovy    


The provided filter operation:

    filter { String 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.

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 12:09:32 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.