Maven Resources Plugin symbolic link handling

Question

In the src/test/resources folder of a maven project there's a relative symbolic link.
With the 2.6 version of the plugin, the actual file is copied.
After updating to the 3.0.1 version, it copies the link instead of the file and on a subsequent run (without clean) fails (mvn -e shows it's because of a FileAlreadyExistsException).
Is there any config option to restore the behavior from the previous version ?
_{I agree, having a link as a test resource is a really bad idea.}

Answer 1

This is a known bug in the maven-resources-plugin: MRESOURCES-237 Resource plugin’s handling of symbolic links changed in 3.0.x, broke existing behaviour, unfixed but known for 1½ years.

Unfortunately, there’s not (yet) a configuration option. Introducing it (and defaulting it to “follow symlinks” instead of copy-preserving them) would fix this issue.

For now, the only solution is to downgrade the maven-resources-plugin. I also upgraded from 2.6, and have just now downgraded to 2.7 (last of the 2.x series), and can confirm that it works around this bug and properly copies the symlinks’ contents.

Update: due to the “Mark invalid” issue (a bug in maven-filtering) you should consider staying with 2.6 if you don’t need any of the new 2.7 features, or have to amend the plugin definition with an updated dependency on maven-filtering 1.3 (or maybe newer).

Answer 2

I can verify that this behavior remains in maven-resources-plugin 3.3.1.

However, by following the Apache issue link included by @mirabilos, I discovered a more recent comment which resolved the issue for me. Specifically, Thorsten Glaser's comment from 07/Jan/22 22:40, reveals a discovery of his.

As long as you don't mind filtering, the plugin will copy your symlinked file, not the symlink.

Turns out that there are three distinct cases, to apply for each directory:

    <filtering>true</filtering> — here, the symlinks are always followed because the files themselves are possibly manipulated
    <filtering>false</filtering> with symlinks followed by default (m-r-p 2.x behaviour)
    <filtering>false</filtering> with symlinks copied as-is (m-r-p 3.0/3.1 behaviour)

So, an example <resource> definition could be:

<resource>
    <directory>src/test/resources</directory>
    <!-- Enable filtering as workaround for symlink issue: https://issues.apache.org/jira/browse/MRESOURCES-237 -->
    <filtering>true</filtering>
    <includes>
        <include>my_symlinked_file</include>
    </includes>
</resource>