[
https://issues.apache.org/jira/browse/MSHARED-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17703080#comment-17703080
]
Tamas Cservenak commented on MSHARED-966:
-----------------------------------------
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).
> 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)
