Exceptions while copying <additionalResources> does not cause build to fail #298
Description
I'm submitting a…
- bug report
- feature request
- other
Short description of the issue/suggestion:
Sometimes we get IOExceptions when the packager is copying files in <additionalResources> to the build folder. The cause was not fond yet, i seems random, and might not be a bug of JavaPackager,
But of those files are not copied the app package wont run.
so any failure when copying those files should result in an aborted build step.
What is the expected behavior?
Build failure when when any file can not be copied.
What is the current behavior?
Build succeeds but files from <additionalResources> are not in the target/${name} folder.
Do you have outputs, screenshots, demos or samples which demonstrate the problem or enhancement?
[INFO] Resources resolved!
[INFO]
[INFO] Copying additional resources
[INFO] Copying file [C:\Users\Till\IdeaProjects\xpert-nba\src\main\deploy\additional\BRi_Pflege.pdf] to folder [C:\Users\Till\IdeaProjects\xpert-nba\target\xpert-nba]
[ERROR] C:\Users\Till\IdeaProjects\xpert-nba\src\main\deploy\additional\BRi_Pflege.pdf -> C:\Users\Till\IdeaProjects\xpert-nba\target\xpert-nba\BRi_Pflege.pdf
[ERROR]
java.lang.Exception: C:\Users\Till\IdeaProjects\xpert-nba\src\main\deploy\additional\BRi_Pflege.pdf -> C:\Users\Till\IdeaProjects\xpert-nba\target\xpert-nba\BRi_Pflege.pdf
at io.github.fvarrui.javapackager.utils.FileUtils.copyFileToFolder (FileUtils.java:97)
at io.github.fvarrui.javapackager.utils.FileUtils.copyFileToFolder (FileUtils.java:83)
at io.github.fvarrui.javapackager.packagers.Packager.lambda$copyAdditionalResources$0 (Packager.java:215)
at java.util.ArrayList$ArrayListSpliterator.forEachRemaining (ArrayList.java:1625)
at java.util.stream.ReferencePipeline$Head.forEach (ReferencePipeline.java:762)
at io.github.fvarrui.javapackager.packagers.Packager.copyAdditionalResources (Packager.java:206)
at io.github.fvarrui.javapackager.packagers.Packager.createApp (Packager.java:393)
at io.github.fvarrui.javapackager.maven.PackageMojo.execute (PackageMojo.java:386)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:77)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:568)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
at org.codehaus.classworlds.Launcher.main (Launcher.java:47)
Caused by: java.nio.file.NoSuchFileException: C:\Users\Till\IdeaProjects\xpert-nba\src\main\deploy\additional\BRi_Pflege.pdf -> C:\Users\Till\IdeaProjects\xpert-nba\target\xpert-nba\BRi_Pflege.pdf
at sun.nio.fs.WindowsException.translateToIOException (WindowsException.java:85)
at sun.nio.fs.WindowsException.rethrowAsIOException (WindowsException.java:103)
at sun.nio.fs.WindowsFileCopy.copy (WindowsFileCopy.java:209)
at sun.nio.fs.WindowsFileSystemProvider.copy (WindowsFileSystemProvider.java:284)
at java.nio.file.Files.copy (Files.java:1305)
at io.github.fvarrui.javapackager.utils.FileUtils.copyFileToFolder (FileUtils.java:92)
at io.github.fvarrui.javapackager.utils.FileUtils.copyFileToFolder (FileUtils.java:83)
at io.github.fvarrui.javapackager.packagers.Packager.lambda$copyAdditionalResources$0 (Packager.java:215)
at java.util.ArrayList$ArrayListSpliterator.forEachRemaining (ArrayList.java:1625)
at java.util.stream.ReferencePipeline$Head.forEach (ReferencePipeline.java:762)
at io.github.fvarrui.javapackager.packagers.Packager.copyAdditionalResources (Packager.java:206)
at io.github.fvarrui.javapackager.packagers.Packager.createApp (Packager.java:393)
at io.github.fvarrui.javapackager.maven.PackageMojo.execute (PackageMojo.java:386)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:77)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:568)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
at org.codehaus.classworlds.Launcher.main (Launcher.java:47)
the build the resumes without his file.
When the build is run again without any changes the file is usually copied.
What is the motivation / use case for changing the behavior?
Behavior could result in broken apps delivered to customers
Please tell us about your environment:
- JavaPackager version: 1.7.0
- OS version: Windows 10 64bit
- JDK version: 17
- Build tool:
- Maven
- Gradle