Filtering of property values containing backslashes in path names still does not escape them?

Are you sure you are using version 2.2 of Maven resources plugin?
Look at your local Maven repository in the path org/apache/maven/plugins/maven-resources-plugin. If there's a directory with name "2.1" you are using the old 2.1 version of the plugin.

I had the same effect as the one you described.
But when I specified in the pom.xml the version 2.2 it worked:

<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>2.2</version>
</plugin>

Alternatively you may delete your local repository. Maven should then get the latest version of the resources plugin.

Hi, thanks for the response.

Well I added

<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>2.2</version>
</plugin>

to my POM, and deleted the directory:

org/apache/maven/plugins/maven-resources-plugin/

from my repository. When a ran mvn again it said:

Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-resources-plugin/2.2/maven-resources-plugin-2.2.pom
1K downloaded
Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-resources-plugin/2.2/maven-resources-plugin-2.2.jar
13K downloaded

The above-mentioned directory was recreated in my repository,
containing (only) subdirectory "2.2/".

There were no more plugin downloads during the build, and nothing
else appeared in my "maven-resource-plugin" directory.

But I still have the same problem! Backslashes are not being escaped.

... I should perhaps add that the filtered resources are being specified
in a <testResources/> in the <build/> section of the POM.

We are seeing this also and are using 2.2

I am not sure that there should be automatic escaping. The problem appears, because the resulting file is later interpreted as a properties file. If the same expansion is used in an xml file:

<location>${basedir}/keys/x509.PFX.MSFT</location>

it will get interpolated to

<location>D:\cygwin\home\dbc\cvs\omii-packaging\source\ws-wss4j/keys/x509.PFX.MSFT</location>

There is no problem at all since backslash is not treated specially in xml.

On the other hand, the xml usage would have problems if the expansion text contains a character with special meaning to xml like an ampersand for example.

It seems hard, to guess the correct escaping rules automatically. It may be better, to allow to specify them explicitly.

Perhaps what is needed is the ability to do something similar to
this:

<resources>
<resource>
<includes>
<include>*.xml</include>
<includes>
<filtering>true</filtering>
</resource>
<resource>
<includes>
<include>*.properties</include>
<includes>
<filtering escapeBackSlash="true">true</filtering>
</resource>
</resources>

An alternative would be a filtering option that just allowed
the standard path-valued macros to be expanded with forward
slashes. In my example if "${basedir}" expanded to:

D:/cygwin/home/dbc/cvs/omii-packaging/source/ws-wss4j

I would be quite happy.

This is, in fact, a problem with interpolation and the issue is already raised in the resources plugin.

I do have the same problem, but I do NOT understand what you are saying. You mean that the "already raised issue" is MRESOURCES-17. This one is closed but I do have the problem with 2.2. Besides: How was the problem fixed? Do have have to configure something?

Hello,

I think it would be great if that issue could be solved, because it will enable ability to share project between unix/linux and windows developpers.

Thx in advance for this work (I can't vote for this Issue)

Guillaume WALLET.