[
https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17618726#comment-17618726
]
Christopher Tubbs commented on MASSEMBLY-941:
---------------------------------------------
[~hboutemy] It took me awhile, but I think I understand the example you gave.
In that case, I think the problem was not the maven-assembly-plugin or mockito,
but the problem was that jvm-repo-rebuild/reproducible-central had a strange
environment. The fix in the referenced PR was reasonable, as it allowed the
mockito team to explicitly declare the file permissions for the archive. That
was reasonable in their case, because all their files had the same permissions.
An alternative could have been for them to modify their build.gradle (or maybe
something in the gradle wrapper properties?) to set the umask before starting
the build.
However, explicitly setting all the files to the same mode is not desired in
the general case.
I've been reading up on what git does with file permissions, and it seems like
when they store files in the git history, they only store 644 or 755, but
nothing else. I think it's okay to use this simplified model for when the mode
isn't explicitly set in the assembly descriptor for a given file set. Git also
has a configuration option to ignore file mode changes, if only the executable
bit is different. This helps avoid checking in (storing) executable bits when
the git worktree is checked out on a badly-behaving filesystem (with respect to
executable bits, like FAT, for example). I'm not sure maven-assembly-plugin
needs to get that complicated... but it would be nice if it preserved
executable flags, so instead of archiving everything as 644, it also used 755,
if the existing file being archived had its executable bit set. I think this
simplified model would be suitable for most everybody.. . and if they need
something more fine-grained, they can create a custom assembly descriptor that
explicitly sets the file modes for the files they want to be different.
> 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)
