You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Ralf Taugerbeck (Jira)" <ji...@apache.org> on 2023/04/03 19:56:00 UTC

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

    [ https://issues.apache.org/jira/browse/MSHARED-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708098#comment-17708098 ] 

Ralf Taugerbeck commented on MSHARED-966:
-----------------------------------------

I can confirm that my original issue is (almost) solved with macOS, Java 17, Maven 3.9.1, and {*}maven-filtering-3.3.1{*}.

With maven-filtering-3.3.0 my little reproducer project still results in an error:
{code:java}
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-resources-plugin:3.3.0:resources (default-resources) on project module-b: copying /Users/foo/workspace/maven-example/module-b/src/main/resources/lib/foo.txt to /Users/foo/workspace/maven-example/module-b/target/classes/lib/foo.txt failed with NoSuchFileException: /Users/foo/workspace/maven-example/module-b/target/classes/lib/foo.txt {code}
Strangely <source> and <target> seem to be inverted in the error message. According to 
{code:java}
<target> <!-- maven-antrun-plugin -->
    <copy todir="${project.basedir}/src/main/resources/lib" flatten="true" overwrite="true" preservelastmodified="true">
       <resources><javaresource name="lib/foo.txt" classpathref="maven.compile.classpath"/></resources>
    </copy>
</target>{code}
it should be the other way around.
{code:java}
[INFO] --- antrun:3.1.0:run (copy-foo) @ module-b ---
[INFO] Executing tasks
[INFO]      [copy] Copying 1 resource to /Users/foo/workspace/maven-example/module-b/src/main/resources/lib
[INFO] Executed tasks {code}
With maven-filtering-3.3.1 it works almost as expected:

I just discovered another small issue. According to
{code:java}
<copy todir="${project.basedir}/src/main/resources/lib" flatten="true" overwrite="true" preservelastmodified="true"> {code}
 the target file should be always overwritten, but if the file at the target location is newer than the source file, it is necessary to run "mvn package" twice...

I just mention this because it might give an indication for other reported issues, but for me maven-filtering-3.3.1 works fine. Thanks for the fix!

> 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)