[ https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17684482#comment-17684482 ]
Christopher Tubbs commented on MASSEMBLY-941: --------------------------------------------- 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)