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

[jira-importer]

Ralf Taugerbeck opened MSHARED-966 and commented

Hi,

after upgrading from 3.1.0 to 3.2.0 I get this weird issue. My build fails with a java.nio.file.NoSuchFileException for a file, that actually exists in the resources directory.

What's special about the file is that it was extracted from a dependency artifact. I know this is a strange use case, but for us it is the only way to supply a common Velocity macro library file to other modules for Velocity template development with IntelliJ (only relative paths supported).

File content and encoding do not seem to have an impact. Could it be because of an archive flag? If I modify and save the file, the build works fine again...

If necessary, I can provide a stack trace or detailed log.

---

Affects: maven-filtering-3.2.0, maven-filtering-3.3.0

Attachments:

• maven.log (116.98 kB)
• maven-example.tgz (1.17 kB)

Issue Links:

• MRESOURCES-278 Regression - Changed copy behaviour if file already exists
  ("causes")
• MSHARED-1004 Two (2) issues with symbolic links

0 votes, 8 watchers

[jira-importer]

Michael Osipov commented

Please provide a log and a sample project if possible.

[jira-importer]

Ralf Taugerbeck commented

maven-example.tgz contains a simple multimodule project to reproduce the issue. In order to do so, you need to run "mvn clean install" 2-3 times

1. to install module-a.jar
2. to extract module-a.jar!/lib/foo.txt to module-b/src/main/resources/lib/foo.txt (the tgz already contains this file. To fully reproduce my scenario, you could remove this file, first)
3. reproduce the build failure because maven-resources-plugin fails to copy module-b/src/main/resources/lib/foo.txt to target/classes

maven.log contains the Maven log from an execution on my machine.

[jira-importer]

Ralf Taugerbeck commented

I could not reproduce this issue on Windows.

[jira-importer]

Michael Osipov commented

Thank, will try to have a look this week.

[jira-importer]

Michael Osipov commented

The bug is in Maven Filtering, not this plugin.

[jira-importer]

Michael Osipov commented

This component is a mess, I tried to bisect, but because snapshot dependencies have been used I cannot locate the error so easily. UGLY! This will take more time than I thought.

[jira-importer]

Andrei Podznoev commented

I'm not sure, but it looks similar to the issue we are having:

after Spring Boot Update 2.3.4 -> 2.4.0,  maven-resource-plugin got updated to 3.2.0 and it has broken our tests, where we copy (automatically, default configuration) test directory with DB configuration, which should be read by TestContainers.

The issue it not reproducible on MacOS, but fails pipelines.

I've spent multiple days so far, to track the issue down, but no luck so far.

[jira-importer]

Sylwester Lachiewicz commented

Fixed with 7e0adf59d190a7d044ade5e5de1b0f0a97676980 

[jira-importer]

Georg Tsakumagos commented

This fix complete changes the behaviour of maven builds.
With this builds are failing if files already exists.
Before this fix existing files do not get overwritten and no exception was thrown.

[jira-importer]

Jimisola Laursen commented

G-Tsak I concur. We have to use mvn clean everywhere now as a workaround.

[jira-importer]

Sylwester Lachiewicz commented

Thx for quick feedback, let's reopen and fix ot correctly

[jira-importer]

Michael Osipov commented

Do not reopen this ticket. It has been addressed in 3.0 and should remain thre. Open a followup ticket. Don't rewrite history.

[jira-importer]

Sylwester Lachiewicz commented

Changes reverted

[jira-importer]

Antoine Tran commented

Hi,

We have a very weird similar issue upgrading from 3.1.0 to 3.2.0. We have a simple copy directive:

 

                        <plugin>
                                <artifactId>maven-resources-plugin</artifactId>
                                <version>3.1.0</version>
                                <executions>
                                        <execution>
                                                <id>copy-resources-docker-dir</id>
                                                <phase>generate-resources</phase>
                                                <goals>
                                                        <goal>copy-resources</goal>
                                                </goals>
                                                <configuration>
                                                        <outputDirectory>${project.build.directory}/${dockername}</outputDirectory>
                                                        <resources>
                                                                <resource>
                                                                        <directory>src/main/docker</directory>
                                                                </resource>
                                                        </resources>
                                                </configuration>
                                        </execution>
                                </executions>
                        </plugin> 

And the expected result is:

 

 

[jenkins@cmt-configurationmanagementtool-jenkins-b67b8f-5t6b8 fci]$ ll /var/lib/jenkins/jobs/l2pf_swci_pi_support-services-sdt/workspace/SIM-SimulatorTool/docker/sim-simulatortool/target/sim-simulatortool/container/sdt/rpm/src/tds-generators-tools/tds-generator/src/tds_app/fci
total 16905
drwxr-xr-x 3 jenkins pigroup 1045470 Sep  6 13:58 amv
drwxr-xr-x 3 jenkins pigroup 1006514 Sep  6 13:58 asr
drwxr-xr-x 3 jenkins pigroup 1073370 Sep  6 13:58 clm
drwxr-xr-x 3 jenkins pigroup 1017545 Sep  6 13:58 crm
drwxr-xr-x 3 jenkins pigroup 1003715 Sep  6 13:58 ct
drwxr-xr-x 3 jenkins pigroup 1018461 Sep  6 13:58 ctth
drwxr-xr-x 2 jenkins pigroup 1000417 Sep  6 13:58 ecmwf
drwxr-xr-x 2 jenkins pigroup 1007825 Sep  6 13:58 fdac
drwxr-xr-x 2 jenkins pigroup 1000168 Sep  6 13:58 fir
drwxr-xr-x 3 jenkins pigroup 1014870 Sep  6 13:58 giitoz
drwxr-xr-x 2 jenkins pigroup 1027650 Sep  6 13:58 idac
drwxr-xr-x 2 jenkins pigroup 1008923 Sep  6 13:58 l1c
drwxr-xr-x 3 jenkins pigroup 1021113 Sep  6 13:58 oca
drwxr-xr-x 3 jenkins pigroup 1002942 Sep  6 13:58 olr
drwxr-xr-x 3 jenkins pigroup 1018429 Sep  6 13:58 rtm
drwxr-xr-x 2 jenkins pigroup 1024893 Sep  6 13:58 sad
drwxr-xr-x 3 jenkins pigroup 1013582 Sep  6 13:58 tsit

The current result with 3.2.0:

[jenkins@cmt-configurationmanagementtool-jenkins-b67b8f-5t6b8 fci]$ ll /var/lib/jenkins/jobs/l2pf_swci_pi_support-services-sdt/workspace/SIM-SimulatorTool/docker/sim-simulatortool/target/sim-simulatortool/container/sdt/rpm/src/tds-generators-tools/tds-generator/src/tds_app/fci
total 4967
drwxr-xr-x 2 jenkins pigroup    3400 Sep  6 13:57 l1c
drwxr-xr-x 3 jenkins pigroup 1021113 Sep  6 13:57 oca
drwxr-xr-x 3 jenkins pigroup 1002942 Sep  6 13:57 olr
drwxr-xr-x 3 jenkins pigroup 1018429 Sep  6 13:57 rtm
drwxr-xr-x 2 jenkins pigroup 1024893 Sep  6 13:57 sad
drwxr-xr-x 3 jenkins pigroup 1013582 Sep  6 13:57 tsit 

I do not understand why some directories disappear. The log, with debug, is like the directories disappeared. It is difficult to make a simple reproducible case. Somehow this is related to a symlink, that if I remove, will make directories reappear again:

[jenkins@cmt-configurationmanagementtool-jenkins-b67b8f-5t6b8 fci]$ mv l1c/idac_deg1_preprocessing.py /tmp/
[jenkins@cmt-configurationmanagementtool-jenkins-b67b8f-5t6b8 fci]$ ll /tmp/idac_deg1_preprocessing.py 
lrwxrwxrwx 1 jenkins pigroup 34 Sep  6 12:23 /tmp/idac_deg1_preprocessing.py -> ../idac/idac_deg1_preprocessing.py 

I lost some hair with that issue, I am reverting back to 3.1.0.

 

[jira-importer]

Tamas Cservenak commented

Regarding original report: the issue is (should be) fixed for sure, as there is not more maven-shared-utils used (so the class org.apache.maven.shared.utils.io.FileUtils.copyFilePermissions is not even on classpath, and new code does explicitly ignores FileNotFoundEx (as assumes is a symlink). This is true for maven-filtering-3.3.0, so unsure why this issue has set "affects" it.

For the hair loss, we'd really like to have a reproducer (which I understand may be difficult).