while filtering resources the token replacement stops at the character @

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

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

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>

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!

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.

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>

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

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

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 ?

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 !

IT for MRESOURCES-104

Should be fixed by : PLXCOMP-150

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

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.

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.

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 $

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 $

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

go, go, go Olivier

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

fixed rev 1052028
SNAPSHOT deployed.

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="$

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

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

<configuration>
<!--<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.

gotama,

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