[ 
https://issues.apache.org/jira/browse/MSHARED-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

G.Vaysman updated MSHARED-1330:
-------------------------------
    Description: 
Under certain SCM's, such as Perforce, files under ./src are read-only. With 
the latest maven-resources-plugin (3.3.1) which has maven-filtering 3.3.1 as a 
dependency, filtered resources end up as read-only in ./target. Since filtered 
resources are always updated in target, this fails with exception below. This 
worked in maven-resources-plugin 2.7, but seems to break, at least, starting 
from maven-resources-plugin 3.0.0. Additionally note, that deprecating certain 
maven-filtering methods (copyFile, etc) that take the Boolean _overwrite_ has 
broken the maven-resource-plugin contract for the resources:resources (see 
[https://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html).]
I am attaching a very simple project that demonstrates it. When unzipping, make 
sure src/main/resources/license.txt is read-only. Execute mvn install twice 
(without "clean") . It fails on both Windows and Linux.  

Suggestion: please, consider passing Boolean _filtering_ all the way to   
FilteringUtils.copyFilePermissions(), and if true, do not apply the read-only 
one.

Error:
 {{Caused by: java.io.FileNotFoundException: 
D:\tmp\create-license\target\classes\license.txt (Access is denied)}}
{{    at java.io.RandomAccessFile.open0 (Native Method)}}
{{    at java.io.RandomAccessFile.open (RandomAccessFile.java:346)}}
{{    at java.io.RandomAccessFile.<init> (RandomAccessFile.java:260)}}
{{    at java.io.RandomAccessFile.<init> (RandomAccessFile.java:215)}}
{{    at org.apache.maven.shared.filtering.FilteringUtils.copyFile 
(FilteringUtils.java:348)}}
{{    at org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile 
(DefaultMavenFileFilter.java:104)}}
{{    at 
org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources
 (DefaultMavenResourcesFiltering.java:268)}}
{{    at org.apache.maven.plugins.resources.ResourcesMojo.execute 
(ResourcesMojo.java:343)}}
{{    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
(DefaultBuildPluginManager.java:137)}}
{{    at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:210) }}

  was:
Under certain SCM's, such as Perforce, files under ./src are read-only. With 
the latest maven-resources-plugin (3.3.1) which has maven-filtering 3.3.1 as a 
dependency, filtered resources end up as read-only in ./target. Since filtered 
resources are always updated in target, this fails with exception below. This 
worked in maven-resources-plugin 2.7, but seems to break, at least, starting 
from maven-resources-plugin 3.0.0. Additionally note, that deprecating certain 
maven-filtering methods (copyFile, etc) that take the Boolean _overwrite_ has 
broken the maven-resource-plugin contract for the resources:resources (see 
[https://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html).]
I am attaching a very simple project that demonstrates it. When unzipping, make 
sure src/main/resources/license.txt is read-only. Execute mvn install twice 
(without "clean") . It fails on both Windows and Linux.  

Suggestion: please, consider passing Boolean filtering all the way to   
FilteringUtils.copyFilePermissions(), and if true, do not apply the read-only 
one.Error:
 {{Caused by: java.io.FileNotFoundException: 
D:\tmp\create-license\target\classes\license.txt (Access is denied)}}
{{    at java.io.RandomAccessFile.open0 (Native Method)}}
{{    at java.io.RandomAccessFile.open (RandomAccessFile.java:346)}}
{{    at java.io.RandomAccessFile.<init> (RandomAccessFile.java:260)}}
{{    at java.io.RandomAccessFile.<init> (RandomAccessFile.java:215)}}
{{    at org.apache.maven.shared.filtering.FilteringUtils.copyFile 
(FilteringUtils.java:348)}}
{{    at org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile 
(DefaultMavenFileFilter.java:104)}}
{{    at 
org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources
 (DefaultMavenResourcesFiltering.java:268)}}
{{    at org.apache.maven.plugins.resources.ResourcesMojo.execute 
(ResourcesMojo.java:343)}}
{{    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
(DefaultBuildPluginManager.java:137)}}
{{    at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:210) }}


> Incremental builds fail on filtered read-only resources  
> ---------------------------------------------------------
>
>                 Key: MSHARED-1330
>                 URL: https://issues.apache.org/jira/browse/MSHARED-1330
>             Project: Maven Shared Components
>          Issue Type: Bug
>          Components: maven-filtering
>            Reporter: G.Vaysman
>            Priority: Major
>         Attachments: create-license.zip
>
>
> Under certain SCM's, such as Perforce, files under ./src are read-only. With 
> the latest maven-resources-plugin (3.3.1) which has maven-filtering 3.3.1 as 
> a dependency, filtered resources end up as read-only in ./target. Since 
> filtered resources are always updated in target, this fails with exception 
> below. This worked in maven-resources-plugin 2.7, but seems to break, at 
> least, starting from maven-resources-plugin 3.0.0. Additionally note, that 
> deprecating certain maven-filtering methods (copyFile, etc) that take the 
> Boolean _overwrite_ has broken the maven-resource-plugin contract for the 
> resources:resources (see 
> [https://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html).]
> I am attaching a very simple project that demonstrates it. When unzipping, 
> make sure src/main/resources/license.txt is read-only. Execute mvn install 
> twice (without "clean") . It fails on both Windows and Linux.  
> Suggestion: please, consider passing Boolean _filtering_ all the way to   
> FilteringUtils.copyFilePermissions(), and if true, do not apply the read-only 
> one.
> Error:
>  {{Caused by: java.io.FileNotFoundException: 
> D:\tmp\create-license\target\classes\license.txt (Access is denied)}}
> {{    at java.io.RandomAccessFile.open0 (Native Method)}}
> {{    at java.io.RandomAccessFile.open (RandomAccessFile.java:346)}}
> {{    at java.io.RandomAccessFile.<init> (RandomAccessFile.java:260)}}
> {{    at java.io.RandomAccessFile.<init> (RandomAccessFile.java:215)}}
> {{    at org.apache.maven.shared.filtering.FilteringUtils.copyFile 
> (FilteringUtils.java:348)}}
> {{    at org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile 
> (DefaultMavenFileFilter.java:104)}}
> {{    at 
> org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources
>  (DefaultMavenResourcesFiltering.java:268)}}
> {{    at org.apache.maven.plugins.resources.ResourcesMojo.execute 
> (ResourcesMojo.java:343)}}
> {{    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:137)}}
> {{    at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:210) }}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to