[MJAR-300] maven jar plugin does not interpret build outputTimestamp correctly

[jira-importer]

Henning Schmiedehausen opened MJAR-300 and commented

consider a minimal project that packages a jar:

% DATE=$(date -Iseconds) ; echo $DATE ; mvn -q clean package ; jar tvf target/jartest-0.1-SNAPSHOT.jar

2024-02-10T21:44:53-08:00

     0 Sat Feb 10 21:44:54 PST 2024 META-INF/
   568 Sat Feb 10 21:44:54 PST 2024 META-INF/MANIFEST.MF
     0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/
     0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/jartest/
     0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/jartest/jartest/
     5 Sat Feb 10 21:44:54 PST 2024 testfile.txt
   575 Sat Feb 10 21:39:50 PST 2024 META-INF/maven/jartest/jartest/pom.xml
    56 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/jartest/jartest/pom.properties

Note how the timestamp returned by the date command and the timestamps of the entries in the jar are basically the same (around 21:44:53 - 21:44:54 on Feb 10th, 2024)

Now use that date as the project build timestamp:

DATE=$(date -Iseconds) ; echo $DATE ; mvn -q -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf target/jartest-0.1-SNAPSHOT.jar
2024-02-10T21:46:30-08:00

     0 Sun Feb 11 05:46:30 PST 2024 META-INF/
   568 Sun Feb 11 05:46:30 PST 2024 META-INF/MANIFEST.MF
     0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/
     0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/
     0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/jartest/
     5 Sun Feb 11 05:46:30 PST 2024 testfile.txt
   575 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/jartest/pom.xml
    56 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/jartest/pom.properties

 

The timestamp and the entries in the jar differ by eight hours (the offset of my local timezone).

When forcing UTC:

DATE=$(TZ=UTC date -Iseconds) ; echo $DATE ; mvn -q -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf target/jartest-0.1-SNAPSHOT.jar

2024-02-11T05:48:22+00:00

     0 Sun Feb 11 05:48:22 PST 2024 META-INF/
   568 Sun Feb 11 05:48:22 PST 2024 META-INF/MANIFEST.MF
     0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/
     0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/
     0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/jartest/
     5 Sun Feb 11 05:48:22 PST 2024 testfile.txt
   575 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/jartest/pom.xml
    56 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/jartest/pom.properties

The timestamp is "correct" but I passed it in as UTC but the jar plugin considers it "local time" and silently attaches PST as timezone. This is where the eight hours discrepancy come from.

This seems to be specific to the outputTimestamp parsing of the jar plugin. 

 

 

 

 

 

 

 

 

---

Affects: 3.3.0

Issue Links:

• MJAR-263 Reproducible Builds: make entries in output jar files reproducible (order + timestamp)
  ("is caused by")

[jira-importer]

Henning Schmiedehausen commented

repo: https://github.com/hgschmie/MJAR-300

[jira-importer]

Henning Schmiedehausen commented

I can track this down to this line in plexus-archiver: https://github.com/codehaus-plexus/plexus-archiver/blob/master/src/main/java/org/codehaus/plexus/archiver/AbstractArchiver.java#L1090

the correct Instant is passed into the method, then the JarArchiver instance ultimately delegates to the AbstractZipArchiver code here: https://github.com/codehaus-plexus/plexus-archiver/blob/master/src/main/java/org/codehaus/plexus/archiver/zip/AbstractZipArchiver.java#L689-L694which assumes that the timestamp is "millis since the epoch in the local timezone". However, the code calling this is passing in "millis since the epoch in UTC" after having converted the timestamp with timezone into UTC first.

this explains the "hours offset from UTC" discrepancy between the timestamp and the actual entries in the jar. 

There is ambiguity between the plexus Archiver#configureReproducibleBuild(FileTime lastModifiedTime) method and the implementation in the AbstractZipArchiver. While the former seems to require the correct timezone, the latter, at least in the zip archiver case, seems to ignore it. 

 

[jira-importer]

Henning Schmiedehausen commented

This is a major (borderline blocking) bug for me as I have code that repackages jars. Without output timestamps, my repackaged jars look like this:

 jar tvf plugin/target/it/test-antlr/target/test-antlr-1.0.under-test.jar  | grep META-INF
     0 Sat Feb 10 21:31:20 PST 2024 META-INF/
     0 Sat Feb 10 21:31:20 PST 2024 META-INF/inlined/
     0 Sat Feb 10 21:31:20 PST 2024 META-INF/inlined/org.antlr/
     0 Sat Feb 10 21:31:20 PST 2024 META-INF/inlined/org.antlr/antlr4-runtime/
     0 Sat Feb 10 21:31:20 PST 2024 META-INF/maven/
     0 Sat Feb 10 21:31:20 PST 2024 META-INF/maven/org.antlr/
     0 Sat Feb 10 21:31:20 PST 2024 META-INF/maven/org.antlr/antlr4-runtime/
     0 Sat Feb 10 21:31:20 PST 2024 META-INF/maven/org.basepom.maven.inline-maven-plugin/
     0 Sat Feb 10 21:31:20 PST 2024 META-INF/maven/org.basepom.maven.inline-maven-plugin/test-antlr/
    81 Sat Feb 10 21:31:20 PST 2024 META-INF/MANIFEST.MF
  2607 Sat Feb 10 21:31:12 PST 2024 META-INF/maven/org.basepom.maven.inline-maven-plugin/test-antlr/pom.xml
    91 Sat Feb 10 21:31:20 PST 2024 META-INF/maven/org.basepom.maven.inline-maven-plugin/test-antlr/pom.properties

 

The last three lines of the jar come from the original jar, the first block is generated by the repackager.

With an output timestamp , this happens:

jar tvf plugin/target/it/test-antlr-reproducible/target/test-antlr-reproducible-1.0.under-test.jar | grep META-INF
     0 Sat Feb 10 15:37:52 PST 2024 META-INF/
     0 Sat Feb 10 15:37:52 PST 2024 META-INF/inlined/
     0 Sat Feb 10 15:37:52 PST 2024 META-INF/inlined/org.antlr/
     0 Sat Feb 10 15:37:52 PST 2024 META-INF/inlined/org.antlr/antlr4-runtime/
     0 Sat Feb 10 15:37:52 PST 2024 META-INF/maven/
     0 Sat Feb 10 15:37:52 PST 2024 META-INF/maven/org.antlr/
     0 Sat Feb 10 15:37:52 PST 2024 META-INF/maven/org.antlr/antlr4-runtime/
     0 Sat Feb 10 15:37:52 PST 2024 META-INF/maven/org.basepom.maven.inline-maven-plugin/
     0 Sat Feb 10 15:37:52 PST 2024 META-INF/maven/org.basepom.maven.inline-maven-plugin/test-antlr-reproducible/
    81 Sat Feb 10 23:37:52 PST 2024 META-INF/MANIFEST.MF
  2717 Sat Feb 10 23:37:52 PST 2024 META-INF/maven/org.basepom.maven.inline-maven-plugin/test-antlr-reproducible/pom.xml
   104 Sat Feb 10 23:37:52 PST 2024 META-INF/maven/org.basepom.maven.inline-maven-plugin/test-antlr-reproducible/pom.properties

The first block (generated by my code) has the correct timestamp. The last three lines (which come from a jar that was packaged with the maven-jar-plugin 3.3.0) do not.  The timestamp is set by a property in the pom.

 

{}technically{}, this is a reproducible build. But it has a wrong, reproducible value (in fact every jar ever packaged with the jar plugin has wrong timestamps). 

 

 

 

 

[jira-importer]

Michael Osipov commented

This is weird, needs more thought. One of the problems with the ZIP definition is that ZIP time is DOS time which is unaware of timezone offsets. We normalize everything to UTC in the DOS time.

Henning Schmiedehausen, please force also UTC on mvn not just date(1).

[jira-importer]

Michael Osipov commented

When TZ is consistently applied everything is fine:

osipovmi@deblndw011x:/tmp/MJAR-300 (main %=)
$ DATE=$(date -Iseconds) ; echo $DATE ; mvn -q -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf target/jartest-0.1-SNAPSHOT.jar
2024-02-11T10:45:55+01:00
^C^C     0 Sun Feb 11 10:45:28 CET 2024 META-INF/
   703 Sun Feb 11 10:45:28 CET 2024 META-INF/MANIFEST.MF
     0 Sun Feb 11 10:45:28 CET 2024 META-INF/maven/
     0 Sun Feb 11 10:45:28 CET 2024 META-INF/maven/jartest/
     0 Sun Feb 11 10:45:28 CET 2024 META-INF/maven/jartest/jartest/
     5 Sun Feb 11 10:45:26 CET 2024 testfile.txt
   575 Sun Feb 11 10:42:36 CET 2024 META-INF/maven/jartest/jartest/pom.xml
    56 Sun Feb 11 10:45:28 CET 2024 META-INF/maven/jartest/jartest/pom.properties
osipovmi@deblndw011x:/tmp/MJAR-300 (main %=)
$ DATE=$(date -Iseconds) ; echo $DATE ; JAVA_VERSION=11 mvn -q -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf target/jartest-0.1-SNAPSHOT.jar
2024-02-11T10:46:07+01:00
     0 Sun Feb 11 09:46:06 CET 2024 META-INF/
   703 Sun Feb 11 09:46:06 CET 2024 META-INF/MANIFEST.MF
     0 Sun Feb 11 09:46:06 CET 2024 META-INF/maven/
     0 Sun Feb 11 09:46:06 CET 2024 META-INF/maven/jartest/
     0 Sun Feb 11 09:46:06 CET 2024 META-INF/maven/jartest/jartest/
     5 Sun Feb 11 09:46:06 CET 2024 testfile.txt
   575 Sun Feb 11 09:46:06 CET 2024 META-INF/maven/jartest/jartest/pom.xml
    56 Sun Feb 11 09:46:06 CET 2024 META-INF/maven/jartest/jartest/pom.properties
osipovmi@deblndw011x:/tmp/MJAR-300 (main %=)
$ DATE=$(TZ=UTC date -Iseconds) ; echo $DATE ; JAVA_VERSION=11 TZ=UTC mvn -q -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf target/jartest-0.1-SNAPSHOT.jar
2024-02-11T09:46:43+00:00
     0 Sun Feb 11 09:46:42 CET 2024 META-INF/
   703 Sun Feb 11 09:46:42 CET 2024 META-INF/MANIFEST.MF
     0 Sun Feb 11 09:46:42 CET 2024 META-INF/maven/
     0 Sun Feb 11 09:46:42 CET 2024 META-INF/maven/jartest/
     0 Sun Feb 11 09:46:42 CET 2024 META-INF/maven/jartest/jartest/
     5 Sun Feb 11 09:46:42 CET 2024 testfile.txt
   575 Sun Feb 11 09:46:42 CET 2024 META-INF/maven/jartest/jartest/pom.xml
    56 Sun Feb 11 09:46:42 CET 2024 META-INF/maven/jartest/jartest/pom.properties
osipovmi@deblndw011x:/tmp/MJAR-300 (main %=)
$ DATE=$(TZ=America/New_York date -Iseconds) ; echo $DATE ; JAVA_VERSION=11 TZ=America/New_York mvn -q -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf target/jartest-0.1-SNAPSHOT.jar
2024-02-11T04:47:59-05:00
     0 Sun Feb 11 09:47:58 CET 2024 META-INF/
   703 Sun Feb 11 09:47:58 CET 2024 META-INF/MANIFEST.MF
     0 Sun Feb 11 09:47:58 CET 2024 META-INF/maven/
     0 Sun Feb 11 09:47:58 CET 2024 META-INF/maven/jartest/
     0 Sun Feb 11 09:47:58 CET 2024 META-INF/maven/jartest/jartest/
     5 Sun Feb 11 09:47:58 CET 2024 testfile.txt
   575 Sun Feb 11 09:47:58 CET 2024 META-INF/maven/jartest/jartest/pom.xml
    56 Sun Feb 11 09:47:58 CET 2024 META-INF/maven/jartest/jartest/pom.properties

I fail to see the issue...

[jira-importer]

Henning Schmiedehausen commented

In your second example: 

2024-02-11T10:46:07+01:00

0 Sun Feb 11 09:46:06 CET 2024 META-INF/

There is a one hour difference between those two values (10:46:xx +01:00 is NOT 09:46:xx CET)

In your third example:

2024-02-11T09:46:43+00:00

0 Sun Feb 11 09:46:42 CET 2024 META-INF/

There is a timezone shift here (+00:00 is NOT CET)

your fourth example I could not reproduce:

DATE=$(TZ=America/New_York date -Iseconds) ; echo $DATE ; TZ=America/New_York mvn -q -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf target/jartest-0.1-SNAPSHOT.jar
2024-02-11T15:18:32-05:00
     0 Sun Feb 11 20:18:32 PST 2024 META-INF/
   699 Sun Feb 11 20:18:32 PST 2024 META-INF/MANIFEST.MF
     0 Sun Feb 11 20:18:32 PST 2024 META-INF/maven/
     0 Sun Feb 11 20:18:32 PST 2024 META-INF/maven/jartest/
     0 Sun Feb 11 20:18:32 PST 2024 META-INF/maven/jartest/jartest/
     5 Sun Feb 11 20:18:32 PST 2024 testfile.txt
   575 Sun Feb 11 20:18:32 PST 2024 META-INF/maven/jartest/jartest/pom.xml
    56 Sun Feb 11 20:18:32 PST 2024 META-INF/maven/jartest/jartest/pom.properties

This still produces an archive with timestamps in my local timezone and 15:18-05:00 would be 12:18-08:00 (PST), we are three hours behind. So the results make even less sense (why would a timestamp of 15:18-05:00 end up being 20:18-08:00?)

 

You literally reproduced the problem in your second and third example with the evidence visible.

 

[jira-importer]

Henning Schmiedehausen commented

the fourth example just reinforces what I wrote:

15:18 -05:00 == 20:18 UTC (b/c America/New_York is five hours behind UTC) and the timestamp in the archive is shown with PST, so it turns into "20:18 PST".

[jira-importer]

Michael Osipov commented

I believe that there is a misunderstanding from your end. Hervé Boutemy and me are intentionally writing UTC time into local time in the ZIP file to have a consistent value. jar(1), zip(1), bsdtar(1) think that this is local time which it is not.
Compare New York and Moscow:

osipovmi@deblndw011x:/tmp/MJAR-300 (main %=)
$ DATE=$(TZ=America/New_York date -Iseconds) ; echo $DATE ; JAVA_VERSION=11 TZ=America/New_York mvn -q -Dproject.build.outputTimestamp=$DATE clean package ; TZ=America/New_York jar tvf target/jartest-0.1-SNAPSHOT.jar
2024-02-11T16:05:54-05:00
     0 Sun Feb 11 21:05:54 EST 2024 META-INF/
   703 Sun Feb 11 21:05:54 EST 2024 META-INF/MANIFEST.MF
     0 Sun Feb 11 21:05:54 EST 2024 META-INF/maven/
     0 Sun Feb 11 21:05:54 EST 2024 META-INF/maven/jartest/
     0 Sun Feb 11 21:05:54 EST 2024 META-INF/maven/jartest/jartest/
     5 Sun Feb 11 21:05:54 EST 2024 testfile.txt
   575 Sun Feb 11 21:05:54 EST 2024 META-INF/maven/jartest/jartest/pom.xml
    56 Sun Feb 11 21:05:54 EST 2024 META-INF/maven/jartest/jartest/pom.properties
osipovmi@deblndw011x:/tmp/MJAR-300 (main %=)
$ DATE=$(TZ=Europe/Moscow date -Iseconds) ; echo $DATE ; JAVA_VERSION=11 TZ=Europe/Moscow mvn -q -Dproject.build.outputTimestamp=$DATE clean package ; TZ=Europe/Moscow jar tvf target/jartest-0.1-SNAPSHOT.jar    2024-02-12T00:06:41+03:00
     0 Sun Feb 11 21:06:40 MSK 2024 META-INF/
   703 Sun Feb 11 21:06:40 MSK 2024 META-INF/MANIFEST.MF
     0 Sun Feb 11 21:06:40 MSK 2024 META-INF/maven/
     0 Sun Feb 11 21:06:40 MSK 2024 META-INF/maven/jartest/
     0 Sun Feb 11 21:06:40 MSK 2024 META-INF/maven/jartest/jartest/
     5 Sun Feb 11 21:06:40 MSK 2024 testfile.txt
   575 Sun Feb 11 21:06:40 MSK 2024 META-INF/maven/jartest/jartest/pom.xml
    56 Sun Feb 11 21:06:40 MSK 2024 META-INF/maven/jartest/jartest/pom.properties

You can ignore the three-letter RFC timezone name. It has no meaning in this context. Here, stil lthe same value:

osipovmi@deblndw011x:/tmp/MJAR-300 (main %=)
$ tar -zvtf target/jartest-0.1-SNAPSHOT.jar
drwxr-xr-x  0 0      0           0 11 Feb. 21:06 META-INF/
-rw-r--r--  0 0      0         703 11 Feb. 21:06 META-INF/MANIFEST.MF
drwxr-xr-x  0 0      0           0 11 Feb. 21:06 META-INF/maven/
drwxr-xr-x  0 0      0           0 11 Feb. 21:06 META-INF/maven/jartest/
drwxr-xr-x  0 0      0           0 11 Feb. 21:06 META-INF/maven/jartest/jartest/
-rw-r--r--  0 0      0           5 11 Feb. 21:06 testfile.txt
-rw-r--r--  0 0      0         575 11 Feb. 21:06 META-INF/maven/jartest/jartest/pom.xml
-rw-r--r--  0 0      0          56 11 Feb. 21:06 META-INF/maven/jartest/jartest/pom.properties
osipovmi@deblndw011x:/tmp/MJAR-300 (main %=)
$ TZ=America/New_York tar -zvtf target/jartest-0.1-SNAPSHOT.jar
drwxr-xr-x  0 0      0           0 11 Feb. 21:06 META-INF/
-rw-r--r--  0 0      0         703 11 Feb. 21:06 META-INF/MANIFEST.MF
drwxr-xr-x  0 0      0           0 11 Feb. 21:06 META-INF/maven/
drwxr-xr-x  0 0      0           0 11 Feb. 21:06 META-INF/maven/jartest/
drwxr-xr-x  0 0      0           0 11 Feb. 21:06 META-INF/maven/jartest/jartest/
-rw-r--r--  0 0      0           5 11 Feb. 21:06 testfile.txt
-rw-r--r--  0 0      0         575 11 Feb. 21:06 META-INF/maven/jartest/jartest/pom.xml
-rw-r--r--  0 0      0          56 11 Feb. 21:06 META-INF/maven/jartest/jartest/pom.properties
osipovmi@deblndw011x:/tmp/MJAR-300 (main %=)
$ TZ=Europe/Moscow tar -zvtf target/jartest-0.1-SNAPSHOT.jar
drwxr-xr-x  0 0      0           0 11 Feb. 21:06 META-INF/
-rw-r--r--  0 0      0         703 11 Feb. 21:06 META-INF/MANIFEST.MF
drwxr-xr-x  0 0      0           0 11 Feb. 21:06 META-INF/maven/
drwxr-xr-x  0 0      0           0 11 Feb. 21:06 META-INF/maven/jartest/
drwxr-xr-x  0 0      0           0 11 Feb. 21:06 META-INF/maven/jartest/jartest/
-rw-r--r--  0 0      0           5 11 Feb. 21:06 testfile.txt
-rw-r--r--  0 0      0         575 11 Feb. 21:06 META-INF/maven/jartest/jartest/pom.xml
-rw-r--r--  0 0      0          56 11 Feb. 21:06 META-INF/maven/jartest/jartest/pom.properties
osipovmi@deblndw011x:/tmp/MJAR-300 (main %=)
$ TZ=Asia/Tokyo tar -zvtf target/jartest-0.1-SNAPSHOT.jar
drwxr-xr-x  0 0      0           0 11 Feb. 21:06 META-INF/
-rw-r--r--  0 0      0         703 11 Feb. 21:06 META-INF/MANIFEST.MF
drwxr-xr-x  0 0      0           0 11 Feb. 21:06 META-INF/maven/
drwxr-xr-x  0 0      0           0 11 Feb. 21:06 META-INF/maven/jartest/
drwxr-xr-x  0 0      0           0 11 Feb. 21:06 META-INF/maven/jartest/jartest/
-rw-r--r--  0 0      0           5 11 Feb. 21:06 testfile.txt
-rw-r--r--  0 0      0         575 11 Feb. 21:06 META-INF/maven/jartest/jartest/pom.xml
-rw-r--r--  0 0      0          56 11 Feb. 21:06 META-INF/maven/jartest/jartest/pom.properties

jar(1) is fooling you here.

[jira-importer]

Hervé Boutemy commented

we intentionally made the magic to have binary result independent from TZ, at the cost of having the result you saw when using unzip

we can revert to have the unzip output independent from TZ: this will lead to the binary output being dependent on TZ

there is no solution to have both advantages at the same time

welcome to the wonders of zip format created in the DOS times: choose your problem

[jira-importer]

Henning Schmiedehausen commented

Hervé Boutemy  I looked at the code in maven-archiver, but I am reluctant to use the archiver; right now I have pretty simple code with a JarOutputStream and writing JarEntry objects into the stream.

I am using the maven archiver code to parse the output timestamp (https://github.com/basepom/inline-maven-plugin/blob/main/plugin/src/main/java/org/basepom/inline/mojo/InlineMojo.java#L278) and use Instant#toEpochMillis() to write the timestamp. This produces a different result than the maven archiver "configureReproducibleBuild" (https://maven.apache.org/shared/maven-archiver/apidocs/org/apache/maven/archiver/MavenArchiver.html#configureReproducibleBuild(java.lang.String)). 

What would be your recommendation? I have no plans to use the JarArchiver or the complex plexus code. Could we document what plugin writers are supposed to do? 

The current behavior seems weird, I am using only standard Java APIs in the most obvious way and that produces a different result than the archiver code. 

(parse Timestamp with maven-archiver -> Instant -> Instant.toEpochMillis() (which is millis since the epoch in GMT) -> ZipEntry#setTime). Would it make more sense to use setLastModifiedTime here (which takes a FileTime)? 

 

Also, it would be good to document how the timestamps in the jar are derived when project.build.outputTimestamp is set. I found next to no documentation besides code. 

 

 

[jira-importer]

Hervé Boutemy commented

What would be your recommendation?

please try to use your code from different TZs and confirm that you get different binaries output.
Then do what you prefer: pay one way or the other, there is no perfect choice, zip format comes from DOS, that does not know what a TZ is: seconds are calculated from local time, not from UTC. Then defining outputTimestamp as UTC based makes zip binary dependent on current TZ

it would be good to document how the timestamps in the jar are derived when project.build.outputTimestamp is set. I found next to no documentation besides code.

help welcome: explaining this in a way that people understand is hard (because it all start by explaining how timestamp is stored in zip with TZ-specific seconds because in fact it ignores TZ. And I won't even try to clarify how extended timestamp in zip file is done like Unix, this time really getting seconds from UTC: that is what lead to MSHADE-420)
I tried in the past, and did not manage to make something that 2 people were able to agree on (and even myself have hard time to read after a few days whatever explanation I wrote)

[jira-importer]

Henning Schmiedehausen commented

Thanks for the response. This is not what I meant; I was asking for "how can I emulate the behavior of the maven archiver?". Right now, it creates different, stable, timestamps for the same project.build.outputTimestamp value, see the example above:

 0 Sat Feb 10 15:37:52 PST 2024 META-INF/maven/org.basepom.maven.inline-maven-plugin/test-antlr-reproducible/
81 Sat Feb 10 23:37:52 PST 2024 META-INF/MANIFEST.MF

The timestamp in the first line is created by a plugin that repackages other jars. The second is from a jar that was created in the same build, right before repackaging. The jar plugin creates the "23:37:52" timestamp, my current code (which I outlined above) creates the "15:37:52" timestamp. I'd like for those to be the same but I am not sure where this goes awry.

 

 

[jira-importer]

Hervé Boutemy commented

Maven Archiver objective is done to zip content from disk, and used in a RB-way does the timezone trick to get stable output binary (zip entry binary output): perhaps what you need is to see the introduction of the trick in plexus-archiver for zip entries (not needed for tar, because tar is UTC based, not local TZ based)
= https://github.com/codehaus-plexus/plexus-archiver/pull/121/files#diff-fdf6dd4c4d1490cc1e2c75fb0b704f6e727d73fba728d8a16725dff8cabf503c

I found one way to perhaps show the issue with DOS-based zip format that does not know about TZ:
on the same .zip file, looking at content from different TZ shows different values:

$ for TZ in Asia/Kolkata Europe/Paris ; do sudo timedatectl set-timezone $TZ ; unzip -l plexus-utils-1.0.4.jar | grep MANIFEST ; jar tvf plexus-utils-1.0.4.jar | grep MANIFEST ; done
      286  2005-10-12 03:57   META-INF/MANIFEST.MF
   286 Wed Oct 12 03:57:46 IST 2005 META-INF/MANIFEST.MF
      286  2005-10-12 03:57   META-INF/MANIFEST.MF
   286 Wed Oct 12 03:57:46 CEST 2005 META-INF/MANIFEST.MF

jar command is better than unzip command, because it makes TZ explicit: zip format is unaware of timezone, then considers it is the machine default timezone

If you want to mimic Maven Archiver to have binary-stable zip entries, you'll need to write an equivalent of normalizeLastModifiedDate()
= https://github.com/codehaus-plexus/plexus-archiver/blob/master/src/main/java/org/codehaus/plexus/archiver/zip/AbstractZipArchiver.java#L688 currently

[jira-importer]

Jorge Solórzano commented

Henning Schmiedehausen Just as additional information:

If you intend to set the timestamp in jars, also check what the jar tool does, there is a --date flag since Java 17.0.3, if you create a jar manually using the jar tool and the --date flag, verify what is the output. This is the official tool from JDK, so you could expect is doing the "right" thing.

"how can I emulate the behavior of the maven archiver?" without using maven archiver, you could also check https://github.com/openjdk/jdk/blob/991e04e7d7ff3ee682c2b8a9b860d325a176e7a5/src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java#L203-L208 and the PR: https://github.com/openjdk/jdk/pull/6481/files

 

[jira-importer]

Henning Schmiedehausen commented

I ended up using the maven archiver parsing code and then pass the timestamp into my code. This should be most compatible and seems to work fine - https://github.com/basepom/inline-maven-plugin/blob/main/plugin/src/main/java/org/basepom/inline/mojo/InlineMojo.java#L278