Maven 2.x Resources Plugin

2.3 escapes characters when filtering properties

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.3
  • Fix Version/s: 2.4
  • Component/s: None
  • Labels:
    None
  • Environment:
    Windows
  • Number of attachments :
    0

Description

When filtering a property additional escaping characters are inserted into the replacement text. Here's an example pom snippett:

    <profiles>
        <profile>
            <id>Automated-Testing-Windows</id>
            <properties>
                <server.resource.type>nt</server.resource.type>
                <server.remote.base.dir>D:\\AutomatedTesting</server.remote.base.dir>
                <server.remote.temp.dir>${server.remote.base.dir}\\temp</server.remote.temp.dir>
            </properties>
        </profile>
  <build>
    <resources>
      <resource>
        <directory>src/main/resources/${server.resource.type}</directory>
        <filtering>true</filtering>
      </resource>
    </resources>
    <resources>
    <plugins>
      <plugin>
        <artifactId>maven-resources-plugin</artifactId>
        <version>2.3</version>
        <executions>
          <execution>
            <id>resources</id>
            <phase>process-resources</phase>
            <goals>
              <goal>resources</goal>
            </goals>
            <configuration>
              <outputDirectory>${project.build.directory}/resources</outputDirectory>
              <includeEmptyDirectories>true</includeEmptyDirectories>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>

and the following line of text in a file in src\main\resources\nt
cd /d $

{server.remote.temp.dir}

Resources plug in version 2.2 filters this property as follows:
cd /d D:\\AutomatedTesting
temp

Resources plug in version 2.3 filters this property differently:
cd /d D\:\\\\AutomatedTesting\\\\temp

Notice the extra backslashes inserted before each backslash (minor issue) and colon (major issue). Is there a way to prevent maven from inserting these escape characters?

I also checked out 2.4-SNAPSHOT revision 732027 and observed the same behavior.

Thanks,
-Paul

Issue Links

depends upon

Improvement - An improvement or enhancement to an existing feature or task. MSHARED-78 FilteringUtils escapeWindowsPath() doesn't work on Windows

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is duplicated by

Bug - A problem which impairs or prevents the functions of the product. MRESOURCES-93 Property substitution of ${project.build.directory} on Windows FAILS

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Improvement - An improvement or enhancement to an existing feature or task. MSHARED-78 FilteringUtils escapeWindowsPath() doesn't work on Windows

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Jason Royals added a comment - - edited

I get the same error too, looks to be caused by MRESOURCES-42

Sometimes escaping the backslash is needed, and sometimes it is not, depending on what is being filtered. In my situation I need to specify $

{builddir}

in an XML file which is filtered. Now I get backslashes in the XML file where they were not before, and the build breaks because the library that uses that XML file is not expecting all that extra escaping.

I wonder if there could be an optional element under the <resource> and <testResource> section of the pom to be able to control at a resources level how characters are escaped. For example:

<resource>
    <directory>src/main/webapp/WEB-INF</directory>
    <filtering>true</filtering>
    <escape>NONE</escape>
    <includes>
        <include>**/*.xml</include>
    </includes>
    <targetPath>../POSPolicyService-FunctionalTest/WEB-INF</targetPath>
</resource>

Possible values could be NONE, JAVA (just escape the backslashes) and PROPERTY (escape colons and backslashes).

Thanks

Show
Jason Royals added a comment - - edited I get the same error too, looks to be caused by MRESOURCES-42 Sometimes escaping the backslash is needed, and sometimes it is not, depending on what is being filtered. In my situation I need to specify $ {builddir} in an XML file which is filtered. Now I get backslashes in the XML file where they were not before, and the build breaks because the library that uses that XML file is not expecting all that extra escaping. I wonder if there could be an optional element under the <resource> and <testResource> section of the pom to be able to control at a resources level how characters are escaped. For example: <resource> <directory>src/main/webapp/WEB-INF</directory> <filtering> true </filtering> <escape>NONE</escape> <includes> <include>**/*.xml</include> </includes> <targetPath>../POSPolicyService-FunctionalTest/WEB-INF</targetPath> </resource> Possible values could be NONE, JAVA (just escape the backslashes) and PROPERTY (escape colons and backslashes). Thanks
Hide
Permalink
John Casey added a comment -

Review for 2.4 release.

Show
John Casey added a comment - Review for 2.4 release.
Hide
Permalink
John Casey added a comment -

new parameter has been introduced: escapeWindowsPaths. This is true by default to preserve backward compat, but can be turned off to disable path escaping.

Show
John Casey added a comment - new parameter has been introduced: escapeWindowsPaths. This is true by default to preserve backward compat, but can be turned off to disable path escaping.
Hide
Permalink
Anders Olsson added a comment -

I agree with Jason above and escapeWindowsPaths seems like a very backward solution to me.

Introducing this change does fix the special case that window paths happen to contain characters that need to be escaped in a certain way if they are later to be interpreted in a certain way. But this breaks existing projects using window paths, which happened to me using xml files.

A cleaner, more complete and backwards compatible fix would be to add optional escaping and providing common schemes as Jason suggests.

Show
Anders Olsson added a comment - I agree with Jason above and escapeWindowsPaths seems like a very backward solution to me. Introducing this change does fix the special case that window paths happen to contain characters that need to be escaped in a certain way if they are later to be interpreted in a certain way. But this breaks existing projects using window paths, which happened to me using xml files. A cleaner, more complete and backwards compatible fix would be to add optional escaping and providing common schemes as Jason suggests.

People

  • Assignee:
    John Casey
    Reporter:
    Paul Jackson
Vote (8)
Watch (11)

Dates

  • Created:
    Updated:
    Resolved: