[jira] [Commented] (MCOMPILER-412) Support --process-module-path
[
https://issues.apache.org/jira/browse/MCOMPILER-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17415817#comment-17415817
]
Anand Beh commented on MCOMPILER-412:
-
FYI for anyone else who happened across this issue, there is a temporary
workaround using the maven-dependency-plugin and specifying the
processor-module-path via a property:
{code:java}
org.apache.maven.plugins
maven-dependency-plugin
set-processorpath-variable
initialize
build-classpath
processor-module-path
org.apache.maven.plugins
maven-compiler-plugin
--processor-module-path
${processor-module-path}
{code}
This worked for my simple use-case.
> Support --process-module-path
> -
>
> Key: MCOMPILER-412
> URL: https://issues.apache.org/jira/browse/MCOMPILER-412
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.8.0, 3.8.1
>Reporter: remi forax
>Priority: Major
>
> {quote}
> In the modular world, javac will look for annotation processor in the
> module-path (only if the annotation processor module is required by the
> module-info, you can use "required static" or uses with the service) and
> javac will also look to the --processor-module-path with again a nice
> separation because the source code doesn't see the module inside the module.
> Everything works cleanly if there is no module-info.java, if you have a
> module-info.java, you have two cases
> 1) your annotation processor is itself a module, if you do a requires on it,
> Maven will put it in the module-path, so it will work (but there is no nice
> separation provided by --processor-module-path)
> 2) your annotation processor is not a module, you can do a require on it but
> Maven will not put it on the module-path because it's not a module, so you
> have to use the of the Maven compiler plugin
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MJAVADOC-677) Using "requires static transitive" makes javadoc goal fail
[ https://issues.apache.org/jira/browse/MJAVADOC-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anand Beh updated MJAVADOC-677: --- Description: Depending on a module using "requires static transitive", and then depending on that module, breaks javadoc execution. *Summary* Module org.checkerframework.checker.qual exists. Module A "requires static transitive org.checkerframework.checker.qual" * Running the javadoc plugin on module A always succeeds. Module B requires module A. * Running the javadoc plugin on module B fails with "module not found: org.checkerframework.checker.qual" This happens only when Module A uses "requires static transitive" on an automatic module. If Module A "requires" or "requires transitive" or "requires static" checker-qual, the javadoc succeeds on Module B. It does not matter whether checker-qual is an automatic module or a full module. The reproducer includes hsqldb 2.6.0 which is a full module, and the same error occurs. *Reproducer* Attached. Also posted at [https://github.com/A248/MJAVADOC-677] *Cause* In target/apidocs/options, the javadoc plugin places checker-qual on the classpath with "--class-path". If checker-qual is placed on the module-path, javadoc execution succeeds. This is demonstrated by editing the options file to place checker-qual on the module path, and running "javadoc @options @argfile". The issue looks like it stems from plexus-java's LocationManager which returns a module-path consisting of required modules but ignoring statically-required modules: [https://github.com/codehaus-plexus/plexus-languages/blob/c1c07b59179bfafd3e80ce82ddd53dae1b2867a7/plexus-java/src/main/java/org/codehaus/plexus/languages/java/jpms/LocationManager.java#L405] *General Solution* Modules specified by "requires static transitive" need to be replaced on the module-path rather than class-path. was: Depending on a module using "requires static transitive", and then depending on that module, breaks javadoc execution. *Summary* Module org.checkerframework.checker.qual exists. Module A "requires static transitive org.checkerframework.checker.qual" * Running the javadoc plugin on module A always succeeds. Module B requires module A. * Running the javadoc plugin on module B fails with "module not found: org.checkerframework.checker.qual" This happens only when Module A uses "requires static transitive" on an automatic module. If Module A "requires" or "requires transitive" or "requires static" checker-qual, the javadoc succeeds on Module B. It does not matter whether checker-qual is an automatic module or a full module. The reproducer includes hsqldb 2.6.0 which is a full module, and the same error occurs. *Reproducer* Attached. *Cause* In target/apidocs/options, the javadoc plugin places checker-qual on the classpath with "--class-path". If checker-qual is placed on the module-path, javadoc execution succeeds. This is demonstrated by editing the options file to place checker-qual on the module path, and running "javadoc @options @argfile". The issue looks like it stems from plexus-java's LocationManager which returns a module-path consisting of required modules but ignoring statically-required modules: [https://github.com/codehaus-plexus/plexus-languages/blob/c1c07b59179bfafd3e80ce82ddd53dae1b2867a7/plexus-java/src/main/java/org/codehaus/plexus/languages/java/jpms/LocationManager.java#L405] *General Solution* Modules specified by "requires static transitive" need to be replaced on the module-path rather than class-path. > Using "requires static transitive" makes javadoc goal fail > -- > > Key: MJAVADOC-677 > URL: https://issues.apache.org/jira/browse/MJAVADOC-677 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.2.0 > Environment: Zulu JDK 16.28+11-CA (build 16+36) > Mac OS 10.14.6 >Reporter: Anand Beh >Priority: Major > Attachments: Javadoc-Modulepath.zip > > > Depending on a module using "requires static transitive", and then depending > on that module, breaks javadoc execution. > *Summary* > Module org.checkerframework.checker.qual exists. > Module A "requires static transitive org.checkerframework.checker.qual" > * Running the javadoc plugin on module A always succeeds. > Module B requires module A. > * Running the javadoc plugin on module B fails with "module not found: > org.checkerframework.checker.qual" > This happens only when Module A uses "requires static transitive" on an > automatic module. If Module A "requires" or "requires transitive" or > "requires static" checker-qual, the javadoc succeeds on Module B. > It does not matter whether checker-qual is an automatic module or a full > module. The reproducer includes hsqldb 2.6.0 which is a f
[jira] [Created] (MJAVADOC-677) Using "requires static transitive" makes javadoc goal fail
Anand Beh created MJAVADOC-677: -- Summary: Using "requires static transitive" makes javadoc goal fail Key: MJAVADOC-677 URL: https://issues.apache.org/jira/browse/MJAVADOC-677 Project: Maven Javadoc Plugin Issue Type: Bug Components: javadoc Affects Versions: 3.2.0 Environment: Zulu JDK 16.28+11-CA (build 16+36) Mac OS 10.14.6 Reporter: Anand Beh Attachments: Javadoc-Modulepath.zip Depending on a module using "requires static transitive", and then depending on that module, breaks javadoc execution. *Summary* Module org.checkerframework.checker.qual exists. Module A "requires static transitive org.checkerframework.checker.qual" * Running the javadoc plugin on module A always succeeds. Module B requires module A. * Running the javadoc plugin on module B fails with "module not found: org.checkerframework.checker.qual" This happens only when Module A uses "requires static transitive" on an automatic module. If Module A "requires" or "requires transitive" or "requires static" checker-qual, the javadoc succeeds on Module B. It does not matter whether checker-qual is an automatic module or a full module. The reproducer includes hsqldb 2.6.0 which is a full module, and the same error occurs. *Reproducer* Attached. *Cause* In target/apidocs/options, the javadoc plugin places checker-qual on the classpath with "--class-path". If checker-qual is placed on the module-path, javadoc execution succeeds. This is demonstrated by editing the options file to place checker-qual on the module path, and running "javadoc @options @argfile". The issue looks like it stems from plexus-java's LocationManager which returns a module-path consisting of required modules but ignoring statically-required modules: [https://github.com/codehaus-plexus/plexus-languages/blob/c1c07b59179bfafd3e80ce82ddd53dae1b2867a7/plexus-java/src/main/java/org/codehaus/plexus/languages/java/jpms/LocationManager.java#L405] *General Solution* Modules specified by "requires static transitive" need to be replaced on the module-path rather than class-path. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MCOMPILER-462) Modular Multi-Release JAR and Maven-Bundle-Plugin together cause inconsistent compilation behavior
[
https://issues.apache.org/jira/browse/MCOMPILER-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anand Beh updated MCOMPILER-462:
Description:
Building a project with a module descriptor placed in a multi-release
directory, and in conjunction with the maven-bundle-plugin, creates
discrepancies between "clean package" and "package" after changes have been
made to the source tree.
This is best explained by reproducing the issue.
*Reproducer*
Attached to this issue. Also clonable from
[https://github.com/A248/ModularMRJAR]
*Steps to reproduce*
# Download the attached reproducer
# *First Run:* Run _mvn package_
# Add a new class, e.g. "Clazz2" in src/main/java/org/mrjar
# *Second Run*: Run _mvn package_
# *Third Run*: Run _mvn clean package_
The Second Run can be repeated any number of times. It will consistently fail
with the reason that the org.mrjar package is not found.
*Results*
* First Run - compilation success
* Second Run - failure
* Third Run - success
The Third Run and the Second Run should compile identically.
*Analysis*
The difference between the second run and the third run is visible using the -X
option.
The trouble happens when compiling the MR classes - i.e., the compile-java11
execution defined in the reproducer's pom.
On the second run, the non-MR classes are placed on the modulepath. The MR
classes fail to compile:
{code:java}
[DEBUG] Classpath:
[DEBUG] Modulepath:
[DEBUG] /Users/anandbeh/git/ModularMRJAR/target/classes
[DEBUG] Source roots:
[DEBUG] /Users/anandbeh/git/ModularMRJAR/src/main/java11
[DEBUG] Command line options:
[DEBUG] -d /Users/anandbeh/git/ModularMRJAR/target/classes/META-INF/versions/11
--module-path /Users/anandbeh/git/ModularMRJAR/target/classes: -sourcepath
/Users/anandbeh/git/ModularMRJAR/src/main/java11:/Users/anandbeh/git/ModularMRJAR/target/generated-sources/annotations:
-s /Users/anandbeh/git/ModularMRJAR/target/generated-sources/annotations -g
-nowarn --release 11 -encoding UTF-8 --module-version 0.1.0-SNAPSHOT{code}
On the third run, the non-MR classes are placed on the classpath. The MR
classes compile. It is further notable that the compiler command line options
differ:
{code:java}
[DEBUG] Classpath:
[DEBUG] /Users/anandbeh/git/ModularMRJAR/target/classes
[DEBUG] Source roots:
[DEBUG] /Users/anandbeh/git/ModularMRJAR/src/main/java11
[DEBUG] Command line options:
[DEBUG] -d /Users/anandbeh/git/ModularMRJAR/target/classes/META-INF/versions/11
-classpath /Users/anandbeh/git/ModularMRJAR/target/classes: -sourcepath
/Users/anandbeh/git/ModularMRJAR/src/main/java11:/Users/anandbeh/git/ModularMRJAR/target/generated-sources/annotations:
-s /Users/anandbeh/git/ModularMRJAR/target/generated-sources/annotations -g
-nowarn --release 11 -encoding UTF-8 --patch-module
org.mrjar=/Users/anandbeh/git/ModularMRJAR/target/classes --module-version
0.1.0-SNAPSHOT{code}
*How to Resolve / Lesson from when not using the maven-bundle-plugin*
If the maven-bundle-plugin were to _NOT_ be used, then:
# The Second Run would succeed.
# The non-MR classes are placed on the class-path consistently.
This suggests the behavior of the Second Run in placing the non-MR classes on
the module-path is incorrect. The Second Run should place the non-MR classes on
the class-path just like the Third Run does.
was:
Building a project with a module descriptor placed in a multi-release
directory, and in conjunction with the maven-bundle-plugin, creates
discrepancies between "clean package" and "package" after changes have been
made to the source tree.
This is best explained by reproducing the issue.
*Reproducer*
Attached to this issue. Also clonable from
[https://github.com/A248/ModularMRJAR]
*Steps to reproduce*
# Download the attached reproducer
# *First Run:* Run _mvn package_
# Add a new class, e.g. "Clazz2" in src/main/java/org/mrjar
# *Second Run*: Run _mvn package_
# *Third Run*: Run _mvn clean package_
The Second Run can be repeated any number of times. It will consistently fail
with the reason that the org.mrjar package is not found.
*Results*
* First Run - compilation success
* Second Run - failure
* Third Run - success
The Third Run and the Second Run should compile identically.
*Analysis*
The difference between the second run and the third run is visible using the -X
option.
The trouble happens when compiling the MR classes - i.e., the compile-java11
execution defined in the reproducer's pom.
On the second run, the non-MR classes are placed on the modulepath. The MR
classes fail to compile:
{code:java}
[DEBUG] Classpath:
[DEBUG] Modulepath:
[DEBUG] /Users/anandbeh/git/ModularMRJAR/target/classes
[DEBUG] Source roots:
[DEBUG] /Users/anandbeh/git/ModularMRJAR/src/main/java11
[DEBUG] Command line options:
[DEBUG] -d /Users/anandbeh/git/ModularMRJAR/target/classes/META-INF/versions/11
--module-path /Users/anandbeh/git/ModularMRJAR/target/cl
[jira] [Created] (MCOMPILER-462) Modular Multi-Release JAR and Maven-Bundle-Plugin together cause inconsistent compilation behavior
Anand Beh created MCOMPILER-462:
---
Summary: Modular Multi-Release JAR and Maven-Bundle-Plugin
together cause inconsistent compilation behavior
Key: MCOMPILER-462
URL: https://issues.apache.org/jira/browse/MCOMPILER-462
Project: Maven Compiler Plugin
Issue Type: Bug
Affects Versions: 3.8.1
Environment: Mac OS 10.14.6
Maven 3.8.1
Maven-Compiler-Plugin 3.8.1
Maven-Bundle-Plugin 5.1.2
Reporter: Anand Beh
Attachments: ModularMRJAR.zip
Building a project with a module descriptor placed in a multi-release
directory, and in conjunction with the maven-bundle-plugin, creates
discrepancies between "clean package" and "package" after changes have been
made to the source tree.
This is best explained by reproducing the issue.
*Reproducer*
Attached to this issue. Also clonable from
[https://github.com/A248/ModularMRJAR]
*Steps to reproduce*
# Download the attached reproducer
# *First Run:* Run _mvn package_
# Add a new class, e.g. "Clazz2" in src/main/java/org/mrjar
# *Second Run*: Run _mvn package_
# *Third Run*: Run _mvn clean package_
The Second Run can be repeated any number of times. It will consistently fail
with the reason that the org.mrjar package is not found.
*Results*
* First Run - compilation success
* Second Run - failure
* Third Run - success
The Third Run and the Second Run should compile identically.
*Analysis*
The difference between the second run and the third run is visible using the -X
option.
The trouble happens when compiling the MR classes - i.e., the compile-java11
execution defined in the reproducer's pom.
On the second run, the non-MR classes are placed on the modulepath. The MR
classes fail to compile:
{code:java}
[DEBUG] Classpath:
[DEBUG] Modulepath:
[DEBUG] /Users/anandbeh/git/ModularMRJAR/target/classes
[DEBUG] Source roots:
[DEBUG] /Users/anandbeh/git/ModularMRJAR/src/main/java11
[DEBUG] Command line options:
[DEBUG] -d /Users/anandbeh/git/ModularMRJAR/target/classes/META-INF/versions/11
--module-path /Users/anandbeh/git/ModularMRJAR/target/classes: -sourcepath
/Users/anandbeh/git/ModularMRJAR/src/main/java11:/Users/anandbeh/git/ModularMRJAR/target/generated-sources/annotations:
-s /Users/anandbeh/git/ModularMRJAR/target/generated-sources/annotations -g
-nowarn --release 11 -encoding UTF-8 --module-version 0.1.0-SNAPSHOT{code}
On the third run, the non-MR classes are placed on the classpath. The MR
classes compile. It is further notable that the compiler command line options
differ:
{code:java}
[DEBUG] Classpath:
[DEBUG] /Users/anandbeh/git/SolarMC/ModularMRJAR/target/classes
[DEBUG] Source roots:
[DEBUG] /Users/anandbeh/git/SolarMC/ModularMRJAR/src/main/java11
[DEBUG] Command line options:
[DEBUG] -d
/Users/anandbeh/git/SolarMC/ModularMRJAR/target/classes/META-INF/versions/11
-classpath /Users/anandbeh/git/SolarMC/ModularMRJAR/target/classes: -sourcepath
/Users/anandbeh/git/SolarMC/ModularMRJAR/src/main/java11:/Users/anandbeh/git/SolarMC/ModularMRJAR/target/generated-sources/annotations:
-s
/Users/anandbeh/git/SolarMC/ModularMRJAR/target/generated-sources/annotations
-g -nowarn --release 11 -encoding UTF-8 --patch-module
org.mrjar=/Users/anandbeh/git/SolarMC/ModularMRJAR/target/classes
--module-version 0.1.0-SNAPSHOT{code}
*How to Resolve / Lesson from when not using the maven-bundle-plugin*
If the maven-bundle-plugin were to _NOT_ be used, then:
# The Second Run would succeed.
# The non-MR classes are placed on the class-path consistently.
This suggests the behavior of the Second Run in placing the non-MR classes on
the module-path is incorrect. The Second Run should place the non-MR classes on
the class-path just like the Third Run does.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[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-
[jira] [Commented] (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 commented on MJAR-275:
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)
[jira] [Commented] (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=17222196#comment-17222196
]
Anand Beh commented on MJAR-275:
Ahh, I see, thank you for investigating this. It's disheartening the JDK patch
version is written to the compiled module-info.class.
It would still be optimal to have MJAR adjust the timestamp in order to achieve
reproducible builds on the same JDK version. For the moment projects can use
the reproducible-build-maven-plugin which forcibly rewrites all timestamps in
the final archive.
> 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)
[jira] [Updated] (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:all-tabpanel
]
Anand Beh updated MJAR-275:
---
Description:
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
was:
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/MCOMPILER-439]
(Source code is also provided as an attachment)
> 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 111
[jira] [Comment Edited] (MCOMPILER-439) outputTimestamp not applied to module-info; breaks reproducible builds
[
https://issues.apache.org/jira/browse/MCOMPILER-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17221654#comment-17221654
]
Anand Beh edited comment on MCOMPILER-439 at 10/27/20, 6:46 PM:
Here is one:
[https://github.com/A248/MCOMPILER-439]
(Source code is also provided as an attachment)
was (Author: a248):
Here is one:
[https://github.com/A248/MCOMPILER-439]
> outputTimestamp not applied to module-info; breaks reproducible builds
> --
>
> Key: MCOMPILER-439
> URL: https://issues.apache.org/jira/browse/MCOMPILER-439
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
> Environment: Mac OS X 10.14.6
> JDK 15 (build 15+36)
> JDK 11 (build 11.0.8+10)
>Reporter: Anand Beh
>Priority: Minor
> Fix For: waiting-for-feedback
>
> 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/MCOMPILER-439]
> (Source code is also provided as an attachment)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MCOMPILER-439) outputTimestamp not applied to module-info; breaks reproducible builds
[
https://issues.apache.org/jira/browse/MCOMPILER-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anand Beh updated MCOMPILER-439:
Description:
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/MCOMPILER-439]
(Source code is also provided as an attachment)
was:
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/MCOMPILER-439
> outputTimestamp not applied to module-info; breaks reproducible builds
> --
>
> Key: MCOMPILER-439
> URL: https://issues.apache.org/jira/browse/MCOMPILER-439
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
> Environment: Mac OS X 10.14.6
> JDK 15 (build 15+36)
> JDK 11 (build 11.0.8+10)
>Reporter: Anand Beh
>Priority: Minor
> Fix For: waiting-for-feedback
>
> 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/Selec
[jira] [Updated] (MCOMPILER-439) outputTimestamp not applied to module-info; breaks reproducible builds
[
https://issues.apache.org/jira/browse/MCOMPILER-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anand Beh updated MCOMPILER-439:
Attachment: MCOMPILER-439.zip
> outputTimestamp not applied to module-info; breaks reproducible builds
> --
>
> Key: MCOMPILER-439
> URL: https://issues.apache.org/jira/browse/MCOMPILER-439
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
> Environment: Mac OS X 10.14.6
> JDK 15 (build 15+36)
> JDK 11 (build 11.0.8+10)
>Reporter: Anand Beh
>Priority: Minor
> Fix For: waiting-for-feedback
>
> 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/MCOMPILER-439
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MCOMPILER-439) outputTimestamp not applied to module-info; breaks reproducible builds
[
https://issues.apache.org/jira/browse/MCOMPILER-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anand Beh updated MCOMPILER-439:
Description:
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/MCOMPILER-439
was:
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.
> outputTimestamp not applied to module-info; breaks reproducible builds
> --
>
> Key: MCOMPILER-439
> URL: https://issues.apache.org/jira/browse/MCOMPILER-439
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
> Environment: Mac OS X 10.14.6
> JDK 15 (build 15+36)
> JDK 11 (build 11.0.8+10)
>Reporter: Anand Beh
>Priority: Minor
> Fix For: waiting-for-feedback
>
> Attachments: 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
[jira] [Commented] (MCOMPILER-439) outputTimestamp not applied to module-info; breaks reproducible builds
[
https://issues.apache.org/jira/browse/MCOMPILER-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17221654#comment-17221654
]
Anand Beh commented on MCOMPILER-439:
-
Here is one:
[https://github.com/A248/MCOMPILER-439]
> outputTimestamp not applied to module-info; breaks reproducible builds
> --
>
> Key: MCOMPILER-439
> URL: https://issues.apache.org/jira/browse/MCOMPILER-439
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
> Environment: Mac OS X 10.14.6
> JDK 15 (build 15+36)
> JDK 11 (build 11.0.8+10)
>Reporter: Anand Beh
>Priority: Minor
> Fix For: waiting-for-feedback
>
> Attachments: 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MCOMPILER-439) outputTimestamp not applied to module-info; breaks reproducible builds
[
https://issues.apache.org/jira/browse/MCOMPILER-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anand Beh updated MCOMPILER-439:
Description:
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.
was:
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}
// code placeholder
-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.
> outputTimestamp not applied to module-info; breaks reproducible builds
> --
>
> Key: MCOMPILER-439
> URL: https://issues.apache.org/jira/browse/MCOMPILER-439
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
> 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: 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
[jira] [Created] (MCOMPILER-439) outputTimestamp not applied to module-info; breaks reproducible builds
Anand Beh created MCOMPILER-439:
---
Summary: outputTimestamp not applied to module-info; breaks
reproducible builds
Key: MCOMPILER-439
URL: https://issues.apache.org/jira/browse/MCOMPILER-439
Project: Maven Compiler Plugin
Issue Type: Bug
Affects Versions: 3.8.1
Environment: Mac OS X 10.14.6
JDK 15 (build 15+36)
JDK 11 (build 11.0.8+10)
Reporter: Anand Beh
Attachments: 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}
// code placeholder
-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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
