Gradle
  1. Gradle
  2. GRADLE-1566

Copy filtering/expansion needs to be more selective on what content is filtered to avoid corrupting binary files

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Resolution: Fixed
    • Affects Version/s: 1.0-milestone-3
    • Fix Version/s: 1.7-rc-1

      Description

      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.

        Activity

        Hide
        Luke Daley added a comment -

        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.

        Show
        Luke Daley added a comment - 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.
        Show
        Luke Daley added a comment - Question raised in forums: http://forums.gradle.org/gradle/topics/whats_a_safe_i_e_cross_platform_way_to_replace_tokens_in_processresources
        Hide
        Merlyn Albery-Speyer added a comment -

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

        processResources {
        inputs.properties( version: version.toString() )
        from(sourceSets.main.resources.srcDirs)

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

        from(sourceSets.main.resources.srcDirs)

        { exclude '**/*.properties' }

        }

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

        Show
        Merlyn Albery-Speyer added a comment - The work-around I'm using for my pain-point is: processResources { inputs.properties( version: version.toString() ) from(sourceSets.main.resources.srcDirs) { include '**/*.properties' filter(org.apache.tools.ant.filters.ReplaceTokens, tokens: [VERSION: version.toString()]) } from(sourceSets.main.resources.srcDirs) { exclude '**/*.properties' } } Note that I'm only seeing corruption of binary files in Linux. None on OSX.
        Hide
        Chuck May added a comment -

        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.

        Show
        Chuck May added a comment - 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.
        Hide
        Jeff Nadler added a comment -

        +1 filtering should not corrupt binary files

        Show
        Jeff Nadler added a comment - +1 filtering should not corrupt binary files
        Hide
        Adam Murdoch added a comment -

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

        Show
        Adam Murdoch added a comment - Can we close this now that we have filesMatching() and filesNotMatching() ?
        Hide
        MikeN added a comment -

        I think so, the following seems to work fine:

        processResources {
            inputs.property('version', version)
        
            filesMatching("**/version.properties") {
                expand version: version
            }
        }
        
        Show
        MikeN added a comment - I think so, the following seems to work fine: processResources { inputs.property('version', version) filesMatching( "**/version.properties" ) { expand version: version } }

          People

          • Assignee:
            Unassigned
            Reporter:
            Luke Daley
          • Votes:
            15 Vote for this issue
            Watchers:
            13 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development