[GRADLE-1566] Copy filtering/expansion needs to be more selective on what content is filtered to avoid corrupting binary files Created: 22/May/11  Updated: 18/Nov/13  Resolved: 18/Nov/13

Status: Resolved
Project: Gradle
Affects Version/s: 1.0-milestone-3
Fix Version/s: 1.7-rc-1

Type: Improvement
Reporter: Luke Daley Assignee: Unassigned
Resolution: Fixed Votes: 15


I have found the filtering and expansion of the war task (and subsequently all copy tasks) to be problematic due to every file being attempted to be read as a text file with a certain encoding. This means that when binary files are read, they are written back out incorrectly.

I have had related problems with the expand() tool and binary files that contain characters that it can't parse.

A potential solution would be to all of the filter/expand operation to operate on a subset of what is being copied.

Comment by Luke Daley [ 22/May/11 ]

Last paragraph should be: “A potential solution would be to have the filter/expand operation(s) operate on a subset of what is being copied.

Comment by Luke Daley [ 19/Sep/11 ]

Question raised in forums: http://forums.gradle.org/gradle/topics/whats_a_safe_i_e_cross_platform_way_to_replace_tokens_in_processresources

Comment by Merlyn Albery-Speyer [ 19/Sep/11 ]

The work-around I'm using for my pain-point is:

processResources {
inputs.properties( version: version.toString() )

{ include '**/*.properties' filter(org.apache.tools.ant.filters.ReplaceTokens, tokens: [VERSION: version.toString()]) }


{ exclude '**/*.properties' }


Note that I'm only seeing corruption of binary files in Linux. None on OSX.

Comment by Chuck May [ 28/May/13 ]

We just ran across this issue and was surprised to find it was reported in 1.0-milestone-3 and still exists 2 years later in 1.6. I see that there is a workaround, but are there any plans on fixing the bug? If not, this issue should just be closed.

Comment by Jeff Nadler [ 05/Jun/13 ]

+1 filtering should not corrupt binary files

Comment by Adam Murdoch [ 11/Nov/13 ]

Can we close this now that we have filesMatching() and filesNotMatching()?

Comment by MikeN [ 17/Nov/13 ]

I think so, the following seems to work fine:

processResources {
    inputs.property('version', version)

    filesMatching("**/version.properties") {
        expand version: version
Generated at Wed Jun 30 11:58:48 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.