[jira] [Comment Edited] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0
[
https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17684482#comment-17684482
]
Christopher Tubbs edited comment on MASSEMBLY-941 at 2/6/23 7:43 AM:
-
One git-specific solution might be to detect that the plugin is running on
files contained within a git repository, and instead of using the
filesystem-detected permissions, just ignore those and use the git-metadata for
the file, {{git ls-files -s path/to/file | cut -c 3-6}}. Or still detect the
executable flag from the filesystem, but instead of preserving it precisely,
simplify it to either 644 or 755, knowing that's all the granularity that git
could have preserved.
was (Author: ctubbsii):
One git-specific solution might be to detect that the plugin is running on
files contained within a git repository, and instead of using the
filesystem-detected permissions, just ignore those and use the git-metadata for
the file, {{git ls-files -s path/to/file | cut -c 3-6}}. Or still detect the
executable flag from the filesystem, but preserving it precisely, simplify it
to either 644 or 755, knowing that's all the granularity that git could have
preserved.
> file permissions removed during assembly:single since 3.2.0
> ---
>
> Key: MASSEMBLY-941
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-941
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: permissions
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Christopher Tubbs
>Assignee: Herve Boutemy
>Priority: Critical
> Fix For: next-release
>
>
> Since MASSEMBLY-921 in 3.2.0, existing file permissions seem to be ignored
> when creating a tarball assembly, and files stored in the assembly do not
> have their original file permissions preserved.
> Using version 3.1.1 of this plugin and earlier, when creating a tar.gz,
> existing file permissions are normally preserved. This is now broken in
> 3.2.0, unless the component descriptor explicitly sets the fileModes.
> This was discovered trying to prepare a release candidate for Apache Accumulo
> using the apache-23.pom parent POM's predefined `source-release-tar`
> descriptor using the `single` goal. We noticed that the resulting
> source-release tarball had stripped all the executable permissions from our
> scripts, instead of preserving them. This makes the resulting source release
> more difficult to build from source.
> A source-release assembly, and any other assembly that does not specify the
> file permissions explicitly, should preserve the existing file permissions,
> just as it used to with 3.1.1 and earlier.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0
[ https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17684457#comment-17684457 ] Herve Boutemy edited comment on MASSEMBLY-941 at 2/6/23 7:13 AM: - just for reference, MASSEMBLY-921 flags were overridden to try to avoid depending on builder's umask configuration when cloning the source code, because usually some people use 002 and others 022 (I won't dig into more exotic cases...), and also avoid the consequences of one builder on Windows (that does not know about execution flag) while the other is on *nix FYI, here is an example of different build results: by default, my local env has umask 002, but reference build was done with umask 022 => I had to add the umask requirement to rebuild with success the affected artifact [https://github.com/jvm-repo-rebuild/reproducible-central/commit/626485c96d069fea2107a8162e8f388b358ebb67] once this new maven-assembly-plugin will be released, such cases will happen more often: I had hoped to avoid this rebuild env prerequisite... was (Author: hboutemy): just for reference, MASSEMBLY-921 flags were overridden to try to avoid depending on builder's umask configuration when cloning the source code, because usually some people use 002 and others 022 (I won't dig into more exotic cases...), and also avoid the consequences of one builder on Windows (that does not know about execution flag) while the other is on *nix FYI, here is an example of different build results: by default, my local env has umask 002, but reference build was done with umask 022 => I had to add the umask requirement to rebuild with success the affected artifact https://github.com/jvm-repo-rebuild/reproducible-central/commit/626485c96d069fea2107a8162e8f388b358ebb67 > file permissions removed during assembly:single since 3.2.0 > --- > > Key: MASSEMBLY-941 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-941 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: permissions >Affects Versions: 3.2.0, 3.3.0 >Reporter: Christopher Tubbs >Assignee: Herve Boutemy >Priority: Critical > Fix For: next-release > > > Since MASSEMBLY-921 in 3.2.0, existing file permissions seem to be ignored > when creating a tarball assembly, and files stored in the assembly do not > have their original file permissions preserved. > Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, > existing file permissions are normally preserved. This is now broken in > 3.2.0, unless the component descriptor explicitly sets the fileModes. > This was discovered trying to prepare a release candidate for Apache Accumulo > using the apache-23.pom parent POM's predefined `source-release-tar` > descriptor using the `single` goal. We noticed that the resulting > source-release tarball had stripped all the executable permissions from our > scripts, instead of preserving them. This makes the resulting source release > more difficult to build from source. > A source-release assembly, and any other assembly that does not specify the > file permissions explicitly, should preserve the existing file permissions, > just as it used to with 3.1.1 and earlier. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0
[ https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17638842#comment-17638842 ] Herve Boutemy edited comment on MASSEMBLY-941 at 11/26/22 3:18 PM: --- fixed in https://github.com/apache/maven-assembly-plugin/commit/f42194b6c0e49bedad506821e524be076e839a79 with an IT to check the 3 different results possible given the 3 types of environment: - Windows 644 (executable flag not detected) - *nix with 755 based on umask - *nix with 775 based on different umask was (Author: hboutemy): fixed in https://github.com/apache/maven-assembly-plugin/commit/f42194b6c0e49bedad506821e524be076e839a79 with an IT to check the 3 different results possible given the 3 types of environment: - Windows (executable flag not detected) - *nix with 755 based on umask - *nix with 775 based on different umask > file permissions removed during assembly:single since 3.2.0 > --- > > Key: MASSEMBLY-941 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-941 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: permissions >Affects Versions: 3.2.0, 3.3.0 >Reporter: Christopher Tubbs >Assignee: Herve Boutemy >Priority: Critical > Fix For: next-release > > > Since 3.2.0, existing file permissions seem to be ignored when creating a > tarball assembly, and files stored in the assembly do not have their original > file permissions preserved. > Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, > existing file permissions are normally preserved. This is now broken in > 3.2.0, unless the component descriptor explicitly sets the fileModes. > This was discovered trying to prepare a release candidate for Apache Accumulo > using the apache-23.pom parent POM's predefined `source-release-tar` > descriptor using the `single` goal. We noticed that the resulting > source-release tarball had stripped all the executable permissions from our > scripts, instead of preserving them. This makes the resulting source release > more difficult to build from source. > A source-release assembly, and any other assembly that does not specify the > file permissions explicitly, should preserve the existing file permissions, > just as it used to with 3.1.1 and earlier. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0
[ https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612461#comment-17612461 ] Herve Boutemy edited comment on MASSEMBLY-941 at 10/4/22 8:41 AM: -- if the issue was introduced in MASSEMBLY-921, it was not intentional: as written in issue description, it was about order and timestamp, not permissions perhaps there was some permissions changes included that I was not aware of we'll need to find where the change was done Edit: now I see that I did the changes, sorry... was (Author: hboutemy): if the issue was introduced in MASSEMBLY-921, it was not intentional: as written in issue description, it was about order and timestamp, not permissions perhaps there was some permissions changes included that I was not aware of we'll need to find where the change was done > file permissions removed during assembly:single since 3.2.0 > --- > > Key: MASSEMBLY-941 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-941 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: permissions >Affects Versions: 3.2.0, 3.3.0 >Reporter: Christopher Tubbs >Priority: Critical > > Since 3.2.0, existing file permissions seem to be ignored when creating a > tarball assembly, and files stored in the assembly do not have their original > file permissions preserved. > Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, > existing file permissions are normally preserved. This is now broken in > 3.2.0, unless the component descriptor explicitly sets the fileModes. > This was discovered trying to prepare a release candidate for Apache Accumulo > using the apache-23.pom parent POM's predefined `source-release-tar` > descriptor using the `single` goal. We noticed that the resulting > source-release tarball had stripped all the executable permissions from our > scripts, instead of preserving them. This makes the resulting source release > more difficult to build from source. > A source-release assembly, and any other assembly that does not specify the > file permissions explicitly, should preserve the existing file permissions, > just as it used to with 3.1.1 and earlier. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0
[ https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509731#comment-17509731 ] Piotr Zygielo edited comment on MASSEMBLY-941 at 10/4/22 8:32 AM: -- This seems to be documented/caused here: https://github.com/codehaus-plexus/plexus-archiver/blob/a4a6b0771148b90221f9e02c0fff9299d45e8520/src/main/java/org/codehaus/plexus/archiver/AbstractArchiver.java#L1326 https://github.com/codehaus-plexus/plexus-archiver/commit/98940db17e3e55ee69646a8b46510f6d1ecad800 https://github.com/codehaus-plexus/plexus-archiver/pull/121 https://github.com/codehaus-plexus/plexus-archiver/pull/121#discussion_r331805108: > This can be quite inconvenient if the archive contains executable scripts > (not uncommon for Java applications). https://github.com/codehaus-plexus/plexus-archiver/pull/121#discussion_r334241220: > yes, executable bit is the most wanted one. was (Author: pzygielo): This seems to be documented/caused here: https://github.com/codehaus-plexus/plexus-archiver/blob/a4a6b0771148b90221f9e02c0fff9299d45e8520/src/main/java/org/codehaus/plexus/archiver/AbstractArchiver.java#L1326 https://github.com/codehaus-plexus/plexus-archiver/commit/98940db17e3e55ee69646a8b46510f6d1ecad800 https://github.com/codehaus-plexus/plexus-archiver/pull/121 > file permissions removed during assembly:single since 3.2.0 > --- > > Key: MASSEMBLY-941 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-941 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: permissions >Affects Versions: 3.2.0, 3.3.0 >Reporter: Christopher Tubbs >Priority: Critical > > Since 3.2.0, existing file permissions seem to be ignored when creating a > tarball assembly, and files stored in the assembly do not have their original > file permissions preserved. > Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, > existing file permissions are normally preserved. This is now broken in > 3.2.0, unless the component descriptor explicitly sets the fileModes. > This was discovered trying to prepare a release candidate for Apache Accumulo > using the apache-23.pom parent POM's predefined `source-release-tar` > descriptor using the `single` goal. We noticed that the resulting > source-release tarball had stripped all the executable permissions from our > scripts, instead of preserving them. This makes the resulting source release > more difficult to build from source. > A source-release assembly, and any other assembly that does not specify the > file permissions explicitly, should preserve the existing file permissions, > just as it used to with 3.1.1 and earlier. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0
[ https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509731#comment-17509731 ] Herve Boutemy edited comment on MASSEMBLY-941 at 10/4/22 8:05 AM: -- This seems to be documented/caused here: https://github.com/codehaus-plexus/plexus-archiver/blob/a4a6b0771148b90221f9e02c0fff9299d45e8520/src/main/java/org/codehaus/plexus/archiver/AbstractArchiver.java#L1326 https://github.com/codehaus-plexus/plexus-archiver/commit/98940db17e3e55ee69646a8b46510f6d1ecad800 https://github.com/codehaus-plexus/plexus-archiver/pull/121 was (Author: pzygielo): This seems to be documented/caused here: https://github.com/codehaus-plexus/plexus-archiver/blob/a4a6b0771148b90221f9e02c0fff9299d45e8520/src/main/java/org/codehaus/plexus/archiver/AbstractArchiver.java#L1326 https://github.com/codehaus-plexus/plexus-archiver/commit/98940db17e3e55ee69646a8b46510f6d1ecad800 > file permissions removed during assembly:single since 3.2.0 > --- > > Key: MASSEMBLY-941 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-941 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: permissions >Affects Versions: 3.2.0, 3.3.0 >Reporter: Christopher Tubbs >Priority: Critical > > Since 3.2.0, existing file permissions seem to be ignored when creating a > tarball assembly, and files stored in the assembly do not have their original > file permissions preserved. > Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, > existing file permissions are normally preserved. This is now broken in > 3.2.0, unless the component descriptor explicitly sets the fileModes. > This was discovered trying to prepare a release candidate for Apache Accumulo > using the apache-23.pom parent POM's predefined `source-release-tar` > descriptor using the `single` goal. We noticed that the resulting > source-release tarball had stripped all the executable permissions from our > scripts, instead of preserving them. This makes the resulting source release > more difficult to build from source. > A source-release assembly, and any other assembly that does not specify the > file permissions explicitly, should preserve the existing file permissions, > just as it used to with 3.1.1 and earlier. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0
[ https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509731#comment-17509731 ] Herve Boutemy edited comment on MASSEMBLY-941 at 10/3/22 11:57 PM: --- This seems to be documented/caused here: https://github.com/codehaus-plexus/plexus-archiver/blob/a4a6b0771148b90221f9e02c0fff9299d45e8520/src/main/java/org/codehaus/plexus/archiver/AbstractArchiver.java#L1326 https://github.com/codehaus-plexus/plexus-archiver/commit/98940db17e3e55ee69646a8b46510f6d1ecad800 was (Author: pzygielo): This seems to be documented/caused here: https://github.com/codehaus-plexus/plexus-archiver/blob/a4a6b0771148b90221f9e02c0fff9299d45e8520/src/main/java/org/codehaus/plexus/archiver/AbstractArchiver.java#L1326 > file permissions removed during assembly:single since 3.2.0 > --- > > Key: MASSEMBLY-941 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-941 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: permissions >Affects Versions: 3.2.0, 3.3.0 >Reporter: Christopher Tubbs >Priority: Critical > > Since 3.2.0, existing file permissions seem to be ignored when creating a > tarball assembly, and files stored in the assembly do not have their original > file permissions preserved. > Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, > existing file permissions are normally preserved. This is now broken in > 3.2.0, unless the component descriptor explicitly sets the fileModes. > This was discovered trying to prepare a release candidate for Apache Accumulo > using the apache-23.pom parent POM's predefined `source-release-tar` > descriptor using the `single` goal. We noticed that the resulting > source-release tarball had stripped all the executable permissions from our > scripts, instead of preserving them. This makes the resulting source release > more difficult to build from source. > A source-release assembly, and any other assembly that does not specify the > file permissions explicitly, should preserve the existing file permissions, > just as it used to with 3.1.1 and earlier. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0
[ https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509731#comment-17509731 ] Piotr Zygielo edited comment on MASSEMBLY-941 at 9/16/22 7:08 AM: -- This seems to be documented/caused here: https://github.com/codehaus-plexus/plexus-archiver/blob/a4a6b0771148b90221f9e02c0fff9299d45e8520/src/main/java/org/codehaus/plexus/archiver/AbstractArchiver.java#L1326 was (Author: pzygielo): This seems to be documented/caused here: https://github.com/codehaus-plexus/plexus-archiver/blob/master/src/main/java/org/codehaus/plexus/archiver/AbstractArchiver.java#L1326 > file permissions removed during assembly:single since 3.2.0 > --- > > Key: MASSEMBLY-941 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-941 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: permissions >Affects Versions: 3.2.0, 3.3.0 >Reporter: Christopher Tubbs >Priority: Critical > > Since 3.2.0, existing file permissions seem to be ignored when creating a > tarball assembly, and files stored in the assembly do not have their original > file permissions preserved. > Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, > existing file permissions are normally preserved. This is now broken in > 3.2.0, unless the component descriptor explicitly sets the fileModes. > This was discovered trying to prepare a release candidate for Apache Accumulo > using the apache-23.pom parent POM's predefined `source-release-tar` > descriptor using the `single` goal. We noticed that the resulting > source-release tarball had stripped all the executable permissions from our > scripts, instead of preserving them. This makes the resulting source release > more difficult to build from source. > A source-release assembly, and any other assembly that does not specify the > file permissions explicitly, should preserve the existing file permissions, > just as it used to with 3.1.1 and earlier. -- This message was sent by Atlassian Jira (v8.20.10#820010)
