You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Anand Beh (Jira)" <ji...@apache.org> on 2021/04/02 14:21:00 UTC
[jira] [Comment Edited] (MJAR-275) outputTimestamp not applied to
module-info; breaks reproducible builds
[ https://issues.apache.org/jira/browse/MJAR-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17313902#comment-17313902 ]
Anand Beh edited comment on MJAR-275 at 4/2/21, 2:20 PM:
---------------------------------------------------------
I may have some good news on the inclusion of JDK patch versions. I took Jorge Solorzano's advice and used the --release flag, with interesting results. Additionally, I added JDK 16 to the analysis matrix.
Using JDK 11 and --release 11, the JDK version includes the patch version as Michael Osipov previously noted:
{code:java}
SourceFile: "module-info.java"
Module:
#5,0 // "me.a248.mjar275"
#0
1 // requires
#6,8000 // "java.base" ACC_MANDATED
#7 // 11.0.10
1 // exports
#8,0 // me/a248/mjar275
0 // opens
0 // uses
0 // provides
{code}
Using JDK 16 and --release 11, the JDK version vanishes:
{code:java}
SourceFile: "module-info.java"
Module:
#6,0 // "me.a248.mjar275"
#0
1 // requires
#8,8000 // "java.base" ACC_MANDATED
#0
1 // exports
#10,0 // me/a248/mjar275
0 // opens
0 // uses
0 // provides{code}
If you would like to reproduce these results, I have updated the reproducer to include module-info.hash.sh.
{code:java}
# Compiles module-info with --release 11
# Uses JDK set by environment
./module-info-hash.sh 11
{code}
Results are as follows:
|| ||JDK 11||JDK 16||
|--release 11|Patch version is present|No version present|
|--release 16|n/a|Appears that the patch version is gone, but not really, because JDK 16 has not had a patch release yet.|
was (Author: a248):
I may have some good news on the inclusion of JDK patch versions. I took Jorge Solorzano's advice and used the --release flag, with interesting results. Additionally, I added JDK 16 to the analysis matrix.
Using JDK 11 and --release 11, the JDK version includes the patch version as Michael Osipov previously noted:
{code:java}
SourceFile: "module-info.java"
Module:
#5,0 // "me.a248.mjar275"
#0
1 // requires
#6,8000 // "java.base" ACC_MANDATED
#7 // 11.0.10
1 // exports
#8,0 // me/a248/mjar275
0 // opens
0 // uses
0 // provides
{code}
{code:java}
{code}
Using JDK 16 and --release 11, the JDK version vanishes:
{code:java}
SourceFile: "module-info.java"
Module:
#6,0 // "me.a248.mjar275"
#0
1 // requires
#8,8000 // "java.base" ACC_MANDATED
#0
1 // exports
#10,0 // me/a248/mjar275
0 // opens
0 // uses
0 // provides{code}
If you would like to reproduce these results, I have updated the reproducer to include module-info.hash.sh.
{code:java}
# Compiles module-info with --release 11
# Uses JDK set by environment
./module-info-hash.sh 11
{code}
Results are as follows:
|| ||JDK 11||JDK 16||
|--release 11|Patch version is present|No version present|
|--release 16|n/a|Appears that the patch version is gone, but not really, because JDK 16 has not had a patch release yet.|
> outputTimestamp not applied to module-info; breaks reproducible builds
> ----------------------------------------------------------------------
>
> Key: MJAR-275
> URL: https://issues.apache.org/jira/browse/MJAR-275
> Project: Maven JAR Plugin
> Issue Type: Bug
> Affects Versions: 3.2.0
> Environment: Mac OS X 10.14.6
> JDK 15 (build 15+36)
> JDK 11 (build 11.0.8+10)
> Reporter: Anand Beh
> Priority: Minor
> Attachments: MCOMPILER-439.zip, Screenshot 2020-10-25 at 2.35.59 PM.png
>
>
> Setting {{project.build.outputTimestamp}} to a fixed value allows creating reproducible builds per this guide: [https://maven.apache.org/guides/mini/guide-reproducible-builds.html |https://maven.apache.org/guides/mini/guide-reproducible-builds.html]However, if one adds a module-info file to the project, reproducible builds break.
> This is caused by module-info.class using the latest timestamp and not {{project.build.outputTimestamp}}. I was able to identify the problem using diffoscope: [https://diffoscope.org/.|https://diffoscope.org/] With it I determined the timestamp across 2 builds was constant for all but the module-info.class:
>
> {code:java}
> -rw---- 2.0 fat 862 bl defN 20-Oct-17 00:40 space/arim/libertybans/api/select/SelectionOrder.class
> │ -rw---- 2.0 fat 1113 bl defN 20-Oct-17 00:40 space/arim/libertybans/api/select/SelectionOrderBuilder.class
> │ -rw---- 2.0 fat 2285 bl defN 20-Oct-17 00:40 META-INF/maven/space.arim.libertybans/bans-api/pom.xml
> │ -rw---- 2.0 fat 74 bl defN 20-Oct-17 00:40 META-INF/maven/space.arim.libertybans/bans-api/pom.properties
> │ --rw---- 2.0 fat 557 bl defN 20-Oct-25 12:39 module-info.class
> │ +-rw---- 2.0 fat 557 bl defN 20-Oct-25 12:41 module-info.class
> {code}
>
> Note the + and - which are diffoscope's way of indicating the difference between the .jar files. Here the {{project.build.outputTimestamp}} is on 17 October. As shown, module-info has a "rebellious" timestamp.
>
> *EDIT:*
> Example project to reproduce the bug:
> [https://github.com/A248/MJAR-275|https://github.com/A248/MCOMPILER-439] (Renamed from [https://github.com/A248/MCOMPILER-439])
> Source code is also provided as an attachment below
--
This message was sent by Atlassian Jira
(v8.3.4#803005)