[
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.
Further, a kind of semi-independent issue is the following: if a module
contains multiple resources, some to be filtered and others not, a typical
Maven pattern is (abridged):
{{ <resources>}}
{{ <resource>}}
{{ <filtering>true</filtering>}}
{{ <includes> ... </includes>}}
{{ </resource>}}
{{ <resource>}}
{{ <filtering>false</filtering>}}
{{ <excludes> ... </excludes>}}
{{ </resource>}}
{{ </resources>}}
This causes both filtered and unfiltered resources go through maven-filtering,
and it breaks incremental builds on unfiltered resources as well.
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.
> Further, a kind of semi-independent issue is the following: if a module
> contains multiple resources, some to be filtered and others not, a typical
> Maven pattern is (abridged):
> {{ <resources>}}
> {{ <resource>}}
> {{ <filtering>true</filtering>}}
> {{ <includes> ... </includes>}}
> {{ </resource>}}
> {{ <resource>}}
> {{ <filtering>false</filtering>}}
> {{ <excludes> ... </excludes>}}
> {{ </resource>}}
> {{ </resources>}}
> This causes both filtered and unfiltered resources go through
> maven-filtering, and it breaks incremental builds on unfiltered resources as
> well.
> 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)
