Maven Resources Plugin
  1. Maven Resources Plugin
  2. MRESOURCES-104

while filtering resources the token replacement stops at the character @

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.4
    • Fix Version/s: 2.5
    • Component/s: None
    • Labels:
      None
    • Environment:
      Windows XP, Java 1.6.0_16

      Description

      Create a simple file hello.txt under src/main/resources with following content:
      "
      This property $

      {testProperty} was replaced
      but the one behind a @ will not be processed, as you
      see: ${testProperty}

      . You shouldn't see a property reference.
      "
      define a build section in your pom.xml like this
      <build>
      <resources>
      <resource>
      <directory>src/main/resources</directory>
      <filtering>true</filtering>
      <includes>
      <include>*/.txt</include>
      </includes>
      </resource>
      <resource>
      <directory>src/main/resources</directory>
      <filtering>false</filtering>
      <excludes>
      <exclude>*/.txt</exclude>
      </excludes>
      </resource>
      </resources>

      Run the command:

      mvn process-resources -DtestProperty=IwasReplaced

      this produces the output

      "
      This property IwasReplaced was replaced
      but the one behind a @ will not be processed, as you
      see: $

      {testProperty}

      . You shouldn't see a property reference.
      "

      As you see, the second property reference was not resolved. The replacement just stops after the @ character.

      1. m3-resource-filtering.zip
        12 kB
        Kevan Dunsmore
      2. MRESOURCES-104.zip
        3 kB
        Arnaud HERITIER

        Issue Links

          Activity

          Hide
          Ian Pojman added a comment -

          this isn't minor.. i just wasted 2 hours because of this

          Show
          Ian Pojman added a comment - this isn't minor.. i just wasted 2 hours because of this
          Hide
          Stephane Nicoll added a comment -

          agreed

          Show
          Stephane Nicoll added a comment - agreed
          Hide
          Gareth Williams added a comment -

          One of the developers I work with was having this problem, he upgraded to maven 2.2.1 and the problem disappeared.
          I'm not saying this will fix everyone's hassles, but its definately worth a try

          Show
          Gareth Williams added a comment - One of the developers I work with was having this problem, he upgraded to maven 2.2.1 and the problem disappeared. I'm not saying this will fix everyone's hassles, but its definately worth a try
          Hide
          Samuel Langlois added a comment -

          I'm afraid I still have the same issue with Maven 2.2.1

          And it is more complex than what the summary suggests.
          For instance, if you add another @ on the second line of the hello.txt above, the filtering is OK.
          I thought it was related to the parity of @, but it's not that simple either.

          A workaround is to stop considering @ as a delimiter in the maven-resources-plugin :
          <plugin>
          <artifactId>maven-resources-plugin</artifactId>
          <configuration>
          <delimiters>
          <delimiter>${*}</delimiter>
          </delimiters>
          <useDefaultDelimiters>false</useDefaultDelimiters>
          </configuration>
          </plugin>

          Show
          Samuel Langlois added a comment - I'm afraid I still have the same issue with Maven 2.2.1 And it is more complex than what the summary suggests. For instance, if you add another @ on the second line of the hello.txt above, the filtering is OK. I thought it was related to the parity of @, but it's not that simple either. A workaround is to stop considering @ as a delimiter in the maven-resources-plugin : <plugin> <artifactId>maven-resources-plugin</artifactId> <configuration> <delimiters> <delimiter>${*}</delimiter> </delimiters> <useDefaultDelimiters>false</useDefaultDelimiters> </configuration> </plugin>
          Hide
          Jochen Stiepel added a comment -

          I have use the workaournd:

           
          <delimiters>
             <delimiter>${*}</delimiter>
          </delimiters>
          

          but even then, the filtering stops, if there is an '@' inside a comment of a java-properties file.

          e.g. a java.properties file with this content:

          
          ########################################################
          
          myemailaddress=${email.address}
          
          # hello world your mail address is: hello@world.com
          
          subject=${email.subject}
          
          ########################################################
          
          

          the 'email.address' will be filtered correctly, but the 'email.subject' not. If I remove the @ in the comment 'hello@world.com' then it works fine!

          Show
          Jochen Stiepel added a comment - I have use the workaournd: <delimiters> <delimiter> ${*} </delimiter> </delimiters> but even then, the filtering stops, if there is an '@' inside a comment of a java-properties file. e.g. a java.properties file with this content: ######################################################## myemailaddress=${email.address} # hello world your mail address is: hello@world.com subject=${email.subject} ######################################################## the 'email.address' will be filtered correctly, but the 'email.subject' not. If I remove the @ in the comment 'hello@world.com' then it works fine!
          Hide
          Thomas Demande added a comment -

          As said before, you should also add:

          <useDefaultDelimiters>false</useDefaultDelimiters>
          

          Otherwise you only add your delimiters to the default ones.

          Works at least for 2.4.1 version, not sure about the previous ones.

          Show
          Thomas Demande added a comment - As said before, you should also add: <useDefaultDelimiters> false </useDefaultDelimiters> Otherwise you only add your delimiters to the default ones. Works at least for 2.4.1 version, not sure about the previous ones.
          Hide
          Jochen Stiepel added a comment -

          Ok, it was my fault. I didn't set useDefaultDelimiters to false:

          <useDefaultDelimiters>false</useDefaultDelimiters>
          

          so the workaround works with this code correctly:

          
          <useDefaultDelimiters>false</useDefaultDelimiters>
          
          <delimiters>
             <delimiter>${*}</delimiter>
          </delimiters>
          
          
          Show
          Jochen Stiepel added a comment - Ok, it was my fault. I didn't set useDefaultDelimiters to false: <useDefaultDelimiters> false </useDefaultDelimiters> so the workaround works with this code correctly: <useDefaultDelimiters> false </useDefaultDelimiters> <delimiters> <delimiter> ${*} </delimiter> </delimiters>
          Hide
          Ian P. Springer added a comment - - edited

          I think the cause of this is that when the template processor encounters the '@' character, it goes into a state where it's looking for a closing '@' character, but it should pop out of this state once it encounters a newline character (since a template variable name will never contain a newline). Once it hits a newline, it should assume the '@' was not the first character of a variable, and just print out the '@' character and the remainder of the line as-is to the target file.

          The read() method in the InterpolationFilterReader from plexus-utils is what is ultimately used to do the replacement of template variables (more specifically, the resources plugin calls maven filtering which calls pluex-utils FileUtils.copyFile(), which is passed a FileUtils$FilterWrapper, which wraps an InterpolationFilterReader).

          It is in InterpolationFilterReader.read() that code needs to be added to check for newlines.

          http://svn.codehaus.org/plexus/plexus-utils/trunk/src/main/java/org/codehaus/plexus/util/InterpolationFilterReader.java

          Show
          Ian P. Springer added a comment - - edited I think the cause of this is that when the template processor encounters the '@' character, it goes into a state where it's looking for a closing '@' character, but it should pop out of this state once it encounters a newline character (since a template variable name will never contain a newline). Once it hits a newline, it should assume the '@' was not the first character of a variable, and just print out the '@' character and the remainder of the line as-is to the target file. The read() method in the InterpolationFilterReader from plexus-utils is what is ultimately used to do the replacement of template variables (more specifically, the resources plugin calls maven filtering which calls pluex-utils FileUtils.copyFile(), which is passed a FileUtils$FilterWrapper, which wraps an InterpolationFilterReader). It is in InterpolationFilterReader.read() that code needs to be added to check for newlines. http://svn.codehaus.org/plexus/plexus-utils/trunk/src/main/java/org/codehaus/plexus/util/InterpolationFilterReader.java
          Hide
          Arnaud HERITIER added a comment -

          30 min left We'll say critical. I'm trying to fix it.

          Show
          Arnaud HERITIER added a comment - 30 min left We'll say critical. I'm trying to fix it.
          Hide
          Arnaud HERITIER added a comment -

          We can test for an end of line, but I think also for a space. I don't think we support variables with spaces. Someone could confirm or negate that ?

          Show
          Arnaud HERITIER added a comment - We can test for an end of line, but I think also for a space. I don't think we support variables with spaces. Someone could confirm or negate that ?
          Hide
          Frédéric Camblor added a comment -

          mvn 3.0-beta1 depends on maven-resources-plugin 2.4.2
          Users using mvn 2.2.1 are using maven-resources-plugin 2.3 which doesn't have the bug ...
          => migration to mvn 3.0-beta1 will produce regression in resources filtering having emails in it !

          Show
          Frédéric Camblor added a comment - mvn 3.0-beta1 depends on maven-resources-plugin 2.4.2 Users using mvn 2.2.1 are using maven-resources-plugin 2.3 which doesn't have the bug ... => migration to mvn 3.0-beta1 will produce regression in resources filtering having emails in it !
          Hide
          Arnaud HERITIER added a comment -
          Show
          Arnaud HERITIER added a comment - IT for MRESOURCES-104
          Hide
          Arnaud HERITIER added a comment -

          Should be fixed by : PLXCOMP-150

          Show
          Arnaud HERITIER added a comment - Should be fixed by : PLXCOMP-150
          Hide
          Daniel N. Lang added a comment -

          this is still an open issue. I've found it out the hard way ... lost 2 hours as well. At least the documentation on the filtering functionality or the plugin as a whole should mention the "@" defaultDelimiter, but I can't find anything on the whole plugin page:
          http://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html

          Show
          Daniel N. Lang added a comment - this is still an open issue. I've found it out the hard way ... lost 2 hours as well. At least the documentation on the filtering functionality or the plugin as a whole should mention the "@" defaultDelimiter, but I can't find anything on the whole plugin page: http://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html
          Hide
          Kevan Dunsmore added a comment -

          Agree with Daniel. Stumbled upon this myself, has taken two hours to get here. Attached is another repro case, showing what works with the default configuration and what does not.

          Show
          Kevan Dunsmore added a comment - Agree with Daniel. Stumbled upon this myself, has taken two hours to get here. Attached is another repro case, showing what works with the default configuration and what does not.
          Hide
          René Zanner added a comment -

          Just a small tip: when you stop filtering/looking for the end of a token always at the end of a line, there wouldn't be any problem. When I use token filters, I would not assume to span it several lines in a file.
          Just look at ANT where the token delimiter '@' is used without those nasty problem.

          Show
          René Zanner added a comment - Just a small tip: when you stop filtering/looking for the end of a token always at the end of a line, there wouldn't be any problem. When I use token filters, I would not assume to span it several lines in a file. Just look at ANT where the token delimiter '@' is used without those nasty problem.
          Hide
          Alexandre Bénard added a comment -

          I confirm the bug on 3.0.1 and 3.0.2-SNAPSHOT (from today) but not on 2.2.1.

          I notice 2 things.
          First, filtering depend on the number of @ before the $

          {testProperty}:
          - odd the ${testProperty}

          is not processed,

          • even the $ {testProperty} is processed.

            Secondly, if you add one @ after the ${testProperty}

            , the all the file is correctly processed.
            So, a workaround could be to add a @ in a comment at the end of the file.

          The first example modify like this works:
          This property $

          {project.version} was replaced
          but the one behind a @ will not be processed, as you
          see: ${project.version}

          . You shouldn't see a property reference.
          But if there is a second @, all the file is correctly processed !!!

          Show
          Alexandre Bénard added a comment - I confirm the bug on 3.0.1 and 3.0.2-SNAPSHOT (from today) but not on 2.2.1. I notice 2 things. First, filtering depend on the number of @ before the $ {testProperty}: - odd the ${testProperty} is not processed, even the $ {testProperty} is processed. Secondly, if you add one @ after the ${testProperty} , the all the file is correctly processed. So, a workaround could be to add a @ in a comment at the end of the file. The first example modify like this works: This property $ {project.version} was replaced but the one behind a @ will not be processed, as you see: ${project.version} . You shouldn't see a property reference. But if there is a second @, all the file is correctly processed !!!
          Hide
          Stephane Nicoll added a comment - - edited

          go, go, go Olivier

          Show
          Stephane Nicoll added a comment - - edited go, go, go Olivier
          Hide
          Olivier Lamy (*$^¨%`£) added a comment -

          xmas gift
          BTW in fact we won't probably support anymore the multi line filtering

          Show
          Olivier Lamy (*$^¨%`£) added a comment - xmas gift BTW in fact we won't probably support anymore the multi line filtering
          Hide
          Olivier Lamy (*$^¨%`£) added a comment -

          fixed rev 1052028
          SNAPSHOT deployed.

          Show
          Olivier Lamy (*$^¨%`£) added a comment - fixed rev 1052028 SNAPSHOT deployed.
          Hide
          gotama added a comment -

          This is still broken in Maven 3.0.3 and maven-resources-plugin 2.5.

          The following is not resource filtered:

          <a href="mailto:email@address.com"><img src="$

          {content.url}

          /images/my.gif"/></a>

          Additionally, using the following work around breaks the pom.xml schema in violation of the required element outputDirectory:

          <configuration>
          <!--<outputDirectory>$

          {project.build.outputDirectory}

          </outputDirectory>-->
          <useDefaultDelimiters>false</useDefaultDelimiters>
          <delimiters>
          <delimiter>${*}</delimiter>
          </delimiters>
          </configuration>

          and, for some reason, uncommenting the above outputDirectory config to forcing defining the value to its default, breaks my hibernate unit tests for some reason due to malconfiguring the datasource.

          Show
          gotama added a comment - This is still broken in Maven 3.0.3 and maven-resources-plugin 2.5. The following is not resource filtered: <a href="mailto:email@address.com"><img src="$ {content.url} /images/my.gif"/></a> Additionally, using the following work around breaks the pom.xml schema in violation of the required element outputDirectory: <configuration> <!--<outputDirectory>$ {project.build.outputDirectory} </outputDirectory>--> <useDefaultDelimiters>false</useDefaultDelimiters> <delimiters> <delimiter>${*}</delimiter> </delimiters> </configuration> and, for some reason, uncommenting the above outputDirectory config to forcing defining the value to its default, breaks my hibernate unit tests for some reason due to malconfiguring the datasource.
          Hide
          Dennis Lundberg added a comment -

          gotama,

          Please open a new issue with a complete test project that we can use to verify your problem.

          Show
          Dennis Lundberg added a comment - gotama, Please open a new issue with a complete test project that we can use to verify your problem.

            People

            • Assignee:
              Olivier Lamy (*$^¨%`£)
              Reporter:
              zealander
            • Votes:
              27 Vote for this issue
              Watchers:
              23 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development