[MSHARED-1004] Two (2) issues with symbolic links

[jira-importer]

Jimisola Laursen opened MSHARED-1004 and commented

Two issues with (relative) symbolic links as resources (use attached file for reference and MWE:

 

user@earhart:~/dev/test/my-app$ tree
.
├── pom.xml
├── src
│   ├── main
│   │   ├── java
│   │   │   └── com
│   │   │       └── mycompany
│   │   │           └── app
│   │   │               └── App.java
│   │   └── resources
│   │       ├── B -> ../../../to_be_symlinked/B
│   │       └── folder -> ../../../to_be_symlinked/folder
│   └── test
│       └── java
│           └── com
│               └── mycompany
│                   └── app
│                       └── AppTest.java
└── to_be_symlinked
    ├── B
    └── folder
        └── A

 

 

 

• Symlinks for directories copies the actual directory (folder/A) whereas symlinks for files copies the symlink (B). Note the difference between file A and B. B is pointing incorrectly since it is relative.

user@earhart:~/dev/test/my-app/target/classes$ ls -l
total 8
lrwxrwxrwx 1 user user   26 dec 10 10:19 B -> ../../../to_be_symlinked/B
drwxrwxr-x 3 user user 4096 dec 10 10:19 com
drwxrwxr-x 2 user user 4096 dec 10 10:19 folder
user@earhart:~/dev/test/my-app/target/classes$ ls -l folder/
total 0
-rw-rw-r-- 1 user user 0 dec 10 10:19 A

• Resources are not overwritten (java.nio.file.FileAlreadyExistsException). To reproduce run "mvn compile" two (2x) times:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-resources-plugin:3.2.0:resources (default-resources) on project my-app: copying /home/user/dev/test/my-app/src/main/resources/folder/A to /home/user/dev/test/my-app/target/classes/folder/A failed with FileAlreadyExistsException: /home/user/dev/test/my-app/target/classes/folder/A -

 

---

Affects: maven-filtering-3.3.0

Attachments:

• my-app.tar.gz (1.56 kB)
• my-app-wo-symlinks.tar.gz (1.50 kB)

Issue Links:

• MSHARED-966 Resources are not copied to ${project.build.outputDirectory}

• MRESOURCES-237 Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

• MRESOURCES-269 Symlinks cause copying resources to fail

[jira-importer]

Jimisola Laursen commented

We thought we had a workaround if we reverse to symlinks, i.e. from resources to outside of src/ but same FileAlreadyExistsException.

So, I removed the symlimks completely and still have the FileAlreadyExistsException. Now I'm starting to think that I've done something wrong.

MWE: [^my-app-wo-symlinks.tar.gz]

ping: Sylwester Lachiewicz 

[jira-importer]

Thorsten Glaser commented

The reverse case is also true, see the comments on https://issues.apache.org/jira/browse/MRESOURCES-237

[jira-importer]

Thorsten Glaser commented

First, making a distinction between what the symlink points to (at copy time) is really useless: it may be dangling in the source but correct in the copied location (I have repositories like that!), and IMHO (see also below), you either follow symlinks encountered in the source directory or you don’t (whether you then also follow symlinks enocountered in the pointed-to directory is another matter, but for consistency with filtering (see below) I think that Maven needs to either follow all symlinks recursively or not touch them at all).

---

Turns out that there are +three+ distinct cases, to apply for each <resource> 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)

And it also turns out I need to be able to mix them in a project, so I’m now even stronger in favour of an option per resource directory (or otherwise configured).