File name filtering does not work when the escapeString is the same as the file separator #289
Description
Affected version
3.3.1
Bug description
On Windows, configure the maven-resources-plugin with fileNameFiltering=true and escapeString=\. Attempt to copy a resource from a subfolder of a resource directory, where the filename begins with a maven property. For example, use the following pom.xml:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.test</groupId>
<artifactId>FileNameFiltering</artifactId>
<version>0.0.1-SNAPSHOT</version>
<name>FileNameFiltering</name>
<description>Reproduction of file name filtering bug</description>
<properties>
<file.name>myFileName</file.name>
</properties>
<build>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>3.3.1</version>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<executions>
<execution>
<id>copy-resources-filter-filename</id>
<phase>process-resources</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${project.build.outputDirectory}</outputDirectory>
<fileNameFiltering>true</fileNameFiltering>
<escapeString>\</escapeString>
<resources>
<resource>
<directory>${project.basedir}/src/main/custom-resources</directory>
<filtering>false</filtering>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
and create empty file src\main\custom-resources\folder\${file.name}.txt. Expected result is the file target\classes\folder\myFileName.txt is created. Instead, target\classes\folder${file.name}.txt is created, where the subdirectory is lost and becomes part of the file name, which is not filtered.
It appears the filtering is applied to the relative path name as a whole, folder\${file.name}.txt, and the file separator is treated as an escape. The filtering should be applied to each file component separately, to remove the conflict with the file separator.
Presumably this can also be reproduced on linux/mac by setting escapeString=/, tho this is more likely to be an issue on Windows, since using escapeString=\ is a common practice.
See the reproduction in this GitHub repo