Maven - resource filtering : implications of the @ symbol in resource files

Question

I am using the Maven assembly plugin to prepare some configuration artifacts for different environments, and I am using resource filtering to substitute parameter values.

Answer 1

Here the link to Maven JIRA issue: https://issues.apache.org/jira/browse/MRESOURCES-141

Filtering doesn't work when there is an odd number of @ in the resource

Answer 2

This seriously works. Define in a properties file as follows:

@=@
emaildomain=example.com

Attempt to set-up an email address using both ${@} and just @.

domain_email=name${@}${emaildomain}
domain_email_using_at=name${@}@emaildomain@
no_domain_email=name@${emaildomain}

Results:
domain_email=name@example.com
domain_email_using_at=name@example.com
no_domain_email=name@${emaildomain}

This should get negative points as it is crazy that it works.

Answer 3

I had the same problem but I could not use Pascal's workaround as @s were part of filtered SQL scripts. So I elaborated on Pascal's solution and haven't found any way how to override default delimiters in Assembly Plugin. However, I've found another useful post (at the very bottom): http://web.archiveorange.com/archive/v/F1XzEmhzIHiBcpS0RyC6

Which suggests using a properly configured resource plugin to copy and filter problematic resources and then use these filtered resources in the assembly plugin. e.g.: (pom.xml)

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-resources-plugin</artifactId>
    <version>2.5</version>
    <executions>
        <execution>
            <id>copy-resources</id>
            <phase>process-resources</phase>
            <goals>
                <goal>copy-resources</goal>
            </goals>
            <configuration>
                <outputDirectory>target/filtered-resources/scripts</outputDirectory>
                <resources>
                    <resource>
                        <directory>src/assemble/resources/scripts</directory>
                        <filtering>true</filtering>
                    </resource>
                </resources>
                <useDefaultDelimiters>false</useDefaultDelimiters>
                <delimiters>
                    <delimiter>${*}</delimiter>
                </delimiters>
            </configuration>
        </execution>
    </executions>
</plugin>

(distribution.xml)

<fileSet>
    <directory>target/filtered-resources/scripts</directory>
...
</fileSet>

Answer 4

i had the same problem, i used a little workaround:

you must mantain '@' char always peer adding a fictitious variable

###########################
author.name@company.com
falsevar=@
############################

env.name=${replacement.value}

Answer 5

You should specify the plugin explicitly in your pom.xml. Implicitly, it is using 2.4.1, which has this issue. You can verify which version maven is using by running maven -X resources:resources.

Version 2.6 fixed this problem.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-resources-plugin</artifactId>
    <version>2.6</version>
</plugin>

Answer 6

I have tried looking for documentation as to why this happens - but cannot find anything that answers this behaviour. Any helpful pointers to documentation or an explanation would be much appreciated.

This is not documented in the filtering section of the Maven Assembly Plugin but it looks like it uses the same default delimiters as the Maven Resources Plugin which are:

<build>
  ...
  <plugin>
    ...
    <configuration>
      ...
      <delimiters>
        <delimiter>${*}</delimiter>
        <delimiter>@</delimiter>
      </delimiters>

So the following would be filtered as well:

env.name=@replacement.value@

And this also explains why a single @ in the email address is causing troubles (the plugin never finds the end delimiter).

It is possible to configure the delimiters and an escape string, just as it is when using the Maven Resources Plugin. The Maven Assembly Plugin documentation for the single goal provides the details.

A cheap workaround, for this particular email address situation, would be to avoid using a single @ in the file to filter:

##############################
# author.name aT company.com #
##############################

env.name=${replacement.value}

And as a benefit, you'll avoid spam :)