[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
The provided filter operation:
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:
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:
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.