Maven 2.x Resources Plugin

while filtering resources the token replacement stops at the character @

Details

  • Type: Bug Bug
  • Status: Closed 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
  • Number of attachments :
    2

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.

Issue Links

This issue is duplicated by:
MRESOURCES-141 Filtering doesn't work when there is an odd number of @ in the resource Major Reopened
MRESOURCES-117 maven-resources-plugin 2.4+ filtering broken Critical Closed
MRESOURCES-112 Default delimiters break filtering Major Closed
MRESOURCES-129 resource:resource filtering fails when resource contains an @ Major Closed
MRESOURCES-133 if "<%@ page import = "java.util.List" %>" is present in a file, filtering does'nt work Major Closed
MRESOURCES-136 Filtering in .properties breaks after encountering @ Major Closed
MRESOURCES-124 @ symbol in filtered resource prevents subsequent filters Minor Closed
This issue relates to:
MRESOURCES-70 Filter does not process nested ${} variables Major Open
This issue depends upon:
PLXCOMP-150 [plexus-interpolator] interpolator functions don't support if delimiter is used for something else (like @ in an email) Major Open
MSHARED-176 Add support of stopping at the end of line to prevent issue with endToken not found Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
Stephane Nicoll added a comment -

agreed

Show
Stephane Nicoll added a comment - agreed
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
Ian 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 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
Permalink
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
Permalink
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
Permalink
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
Permalink
Arnaud Heritier added a comment -

IT for MRESOURCES-104

Show
Arnaud Heritier added a comment - IT for MRESOURCES-104
Hide
Permalink
Arnaud Heritier added a comment -

Should be fixed by : PLXCOMP-150

Show
Arnaud Heritier added a comment - Should be fixed by : PLXCOMP-150
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
Stephane Nicoll added a comment - - edited

go, go, go Olivier

Show
Stephane Nicoll added a comment - - edited go, go, go Olivier
Hide
Permalink
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
Permalink
Olivier Lamy added a comment -

fixed rev 1052028
SNAPSHOT deployed.

Show
Olivier Lamy added a comment - fixed rev 1052028 SNAPSHOT deployed.
Hide
Permalink
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
Permalink
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

Vote (27)
Watch (27)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.