[
https://issues.apache.org/jira/browse/MSHARED-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600782#comment-17600782
]
Antoine Tran commented on MSHARED-966:
--------------------------------------
Hi,
We have a very weird similar issue upgrading from 3.1.0 to 3.2.0. We have a
simple copy directive:
{code:java}
<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> {code}
And the expected result is:
{code:java}
[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{code}
The current result with 3.2.0:
{code:java}
[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 {code}
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:
{code:java}
[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 {code}
I lost some hair with that issue, I am reverting back to 3.1.0.
> Resources are not copied to ${project.build.outputDirectory}
> ------------------------------------------------------------
>
> Key: MSHARED-966
> URL: https://issues.apache.org/jira/browse/MSHARED-966
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
> Affects Versions: maven-filtering-3.2.0, maven-filtering-3.3.0
> Environment: Maven 3.6.3, Java 11, macOS
> Reporter: Ralf Taugerbeck
> Priority: Major
> Attachments: maven-example.tgz, maven.log
>
>
> 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
