[
https://issues.apache.org/jira/browse/MASSEMBLY-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17695006#comment-17695006
]
Niels Basjes commented on MASSEMBLY-975:
----------------------------------------
At this moment I see a few more points on this:
*Communicate buildinfo with each release*
Communicate all relevant build environment settings chosen by the developer
during the release for a rebuilder to be able to fully reproduce it.
Essentially just persist the umask in the generated .buildinfo file just as is
done with the java.version and os.name for platforms where it is a relevant
flag (i.e. Unix/Linux/Mac).
This way the developer can use the umask and other settings any way they like
and a rebuilder can reproduce it correctly by following the specified settings.
{code:java}
# build environment information (simplified for reproducibility)
java.version=8
os.name=Unix
umask=0022
{code}
Perhaps other settings should be included aswell? timezone? locale? language?
...
For rebuilding we can then just build a docker image with these exact settings.
Key requirement is that this requires this buildinfo file to be published with
the artifacts so it can be retrieved again for verification.
Also: A tool is really needed for developers to verify their project without
the need to actually deploy it to maven central.
*Multiple JDKs*
Some projects have the need for multiple JDK versions during the build with
toolchains.
My project [https://github.com/nielsbasjes/yauaa] needs this because it builds
plugins/udfs for several environments with very specific Java version
requirements.
In [https://github.com/jvm-repo-rebuild/reproducible-central/pull/104] I have a
draft / proof of concept that simply always includes all LTS versions of Java.
So the buildinfo should have
* The java version under which the build is run: java.version=11
* The JDK versions available during build (with toolchains!): jdk.version=8
|11|17
* If jdk.version is missing then it is set to the same value as java.version
This multiple JDK idea does need a simple setting for the artifact:buildinfo
goal to indicate which JDKs a project needs.
*Easy reproducible*
This also opens the route to have a standardized application (maven plugin?) so
anyone can verify a project by simply specifying the group, artifact and
version.
- Find buildinfo of that artifact (which may be published with a parent pom)
is retrieved from the maven repository.
- Setup a build environment with these specs (including umask)
- Source of the specified tag is cloned from the specified source repo.
- Rebuild and verify.
*Warn about non reproducible*
All affected maven plugins should warn if the build is platform specific and
have a setting to fix it.
Similar what happens if you do not have project.build.sourceEncoding set; many
plugins give a warning about that.
So in this case the assembly plugin warns when the fileMode and directoryMode
are absent because the umask may affect that.
> Regression: 3.5.0 no longer uses default fileMode and directoryMode
> -------------------------------------------------------------------
>
> Key: MASSEMBLY-975
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-975
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Affects Versions: 3.5.0
> Reporter: Niels Basjes
> Priority: Critical
>
> If the fileMode and directoryMode have not been specified with the 3.5.0
> version then the umask of the system at hand will determine the permissions
> of the files in the jar generated by the assembly plugin.
> This is a bug because it has been documented that it should use the
> documented defaults in this case.
> If I change the version of the plugin from 3.5.0 to 3.4.2 then it works as
> expected.
> I made a simple reproduction project:
> https://github.com/nielsbasjes/BugreportMavenAssemblyUMask
> This builds the same trivial project (with 3 different umask settings) and
> assembles a jar with the default and explicitly set the same as the
> documented defaults.
> The base files are all the same (md5sum output)
> {code}
> ec364137a2c7678ef0c8f495652efe36 target-0002/assemblyumask-1.0-SNAPSHOT.jar
> ec364137a2c7678ef0c8f495652efe36 target-0022/assemblyumask-1.0-SNAPSHOT.jar
> ec364137a2c7678ef0c8f495652efe36 target-0055/assemblyumask-1.0-SNAPSHOT.jar
> {code}
> The maven-assembly-plugin created files WITH fileMode and directoryMode are
> all the same
> {code}
> ba12113ad2b95a4fc75d99aa5bfd4e4f
> target-0002/assemblyumask-1.0-SNAPSHOT-udf-mode.jar
> ba12113ad2b95a4fc75d99aa5bfd4e4f
> target-0022/assemblyumask-1.0-SNAPSHOT-udf-mode.jar
> ba12113ad2b95a4fc75d99aa5bfd4e4f
> target-0055/assemblyumask-1.0-SNAPSHOT-udf-mode.jar
> {code}
> The maven-assembly-plugin created files WITHOUT fileMode and directoryMode
> are all different
> {code}
> 316e5d6b2e85b7d829e938a5797370d7
> target-0022/assemblyumask-1.0-SNAPSHOT-udf-default.jar
> 3375500189ef3087f8943d518209a5e6
> target-0055/assemblyumask-1.0-SNAPSHOT-udf-default.jar
> c341cbbc9f21bb64b817b8bbdaae8608
> target-0002/assemblyumask-1.0-SNAPSHOT-udf-default.jar
> {code}
> The permissions IN the files are the difference:
> {code}
> $ diffoscope target-0055/assemblyumask-1.0-SNAPSHOT-udf-mode.jar
> target-0055/assemblyumask-1.0-SNAPSHOT-udf-default.jar
> --- target-0055/assemblyumask-1.0-SNAPSHOT-udf-mode.jar
> +++ target-0055/assemblyumask-1.0-SNAPSHOT-udf-default.jar
> │┄ Archive contents identical but files differ, possibly due to different
> compression levels. Falling back to binary comparison.
> ├── zipinfo {}
> │ @@ -1,13 +1,13 @@
> │ Zip file size: 2152173 bytes, number of entries: 1515
> │ drwxr-xr-x 2.0 unx 0 b- stor 03-Mar-03 03:03 META-INF/
> │ -rw-r--r-- 2.0 unx 79 b- defN 03-Mar-03 03:03 META-INF/MANIFEST.MF
> │ -drwxr-xr-x 2.0 unx 0 b- stor 03-Mar-03 03:03 nl/
> │ -drwxr-xr-x 2.0 unx 0 b- stor 03-Mar-03 03:03 nl/basjes/
> │ -drwxr-xr-x 2.0 unx 0 b- stor 03-Mar-03 03:03 nl/basjes/bugreports/
> │ +drwx-w--w- 2.0 unx 0 b- stor 03-Mar-03 03:03 nl/
> │ +drwx-w--w- 2.0 unx 0 b- stor 03-Mar-03 03:03 nl/basjes/
> │ +drwx-w--w- 2.0 unx 0 b- stor 03-Mar-03 03:03 nl/basjes/bugreports/
> │ drwxr-xr-x 2.0 unx 0 b- stor 03-Mar-03 03:03 META-INF/org/
> │ drwxr-xr-x 2.0 unx 0 b- stor 03-Mar-03 03:03 META-INF/org/apache/
> │ drwxr-xr-x 2.0 unx 0 b- stor 03-Mar-03 03:03
> META-INF/org/apache/logging/
> │ drwxr-xr-x 2.0 unx 0 b- stor 03-Mar-03 03:03
> META-INF/org/apache/logging/log4j/
> │ drwxr-xr-x 2.0 unx 0 b- stor 03-Mar-03 03:03
> META-INF/org/apache/logging/log4j/core/
> │ drwxr-xr-x 2.0 unx 0 b- stor 03-Mar-03 03:03
> META-INF/org/apache/logging/log4j/core/config/
> │ drwxr-xr-x 2.0 unx 0 b- stor 03-Mar-03 03:03
> META-INF/org/apache/logging/log4j/core/config/plugins/
> │ @@ -1508,10 +1508,10 @@
> │ -rw-r--r-- 2.0 unx 223 b- defN 03-Mar-03 03:03
> org/apache/logging/log4j/util/Unbox$1.class
> │ -rw-r--r-- 2.0 unx 1135 b- defN 03-Mar-03 03:03
> org/apache/logging/log4j/util/Unbox$State.class
> │ -rw-r--r-- 2.0 unx 1779 b- defN 03-Mar-03 03:03
> org/apache/logging/log4j/util/Unbox$WebSafeState.class
> │ -rw-r--r-- 2.0 unx 4595 b- defN 03-Mar-03 03:03
> org/apache/logging/log4j/util/Unbox.class
> │ -rw-r--r-- 2.0 unx 135 b- defN 03-Mar-03 03:03
> org/apache/logging/log4j/util/package-info.class
> │ -rw-r--r-- 2.0 unx 6283 b- defN 03-Mar-03 03:03
> META-INF/maven/org.apache.logging.log4j/log4j-api/pom.xml
> │ -rw-r--r-- 2.0 unx 69 b- defN 03-Mar-03 03:03
> META-INF/maven/org.apache.logging.log4j/log4j-api/pom.properties
> │ --rw-r--r-- 2.0 unx 494 b- defN 03-Mar-03 03:03 log4j2.xml
> │ --rw-r--r-- 2.0 unx 605 b- defN 03-Mar-03 03:03
> nl/basjes/bugreports/App.class
> │ +-rw-rw-r-- 2.0 unx 494 b- defN 03-Mar-03 03:03 log4j2.xml
> │ +-rw--w--w- 2.0 unx 605 b- defN 03-Mar-03 03:03
> nl/basjes/bugreports/App.class
> │ 1515 files, 4853233 bytes uncompressed, 1839331 bytes compressed: 62.1%
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
