Add ability to NOT write timestamps for zip file entries

[danielwegener]

To be discussed:
Thinking in reproducible builds, It would be great if we could see build tools that use plexus-archiver as pure transformers/functions - given the same input - will always produce the same output (at least if they are used synchronous and always provide the same input in the same sequence). This is however currently not possible using maven-archiver (transitively using plexus-archiver) because the AbstractZipArchiver will always create ZipEntry timestamps. I wish there was a property to AbstractZipArchiver like private boolean createZipEntryTime = true; to turn the setTime behaviour off.

I'd be happy to submit a PR if this feature is desirable (is there maybe something in the jar spec that insists on these fields? I have not found any reference).

[michael-o]

What timestamp should be written then (instead of)?

[danielwegener]

I thought modificationTime/Date was be an optional field in the ZIP file format, but https://www.iana.org/assignments/media-types/application/zip says its not. So my initial idea would be to set the field to 0/epoch.

This is also what reproducible-builds-maven-plugin is doing.

[michael-o]

The timestamp of the class file shouldn't change if the class has not be recompiled, should it? How do you define a reproducible build in this case?

[danielwegener]

I mean that mvn clean install on the same input and environment should always produce the same output. The time when the build is executed just should not matter. class files are just intermediate artifacts that should be recreatable without changing the result of the whole build result.

[sewe]

I think the Plexus archiver should allow its caller to explicitly set a single, fixed timestamp which will be used for all entries. If the timestamp is not set, then the Plexus archiver should default to its current behavior: using the modification timestamps of the entries to be archive.

If this single timestamp is then exposed as <archive> configuration of the maven-jar-plugin and friends, one can set it explicitly, e.g., to the time when the commit being build was made.

[krosenvold]

Would it make more sense to actually adjust the timestamp of the .class file to match the source file ? (I'm thinking about an additional plugin/step that ensures this behaviour)

[danielwegener]

@sewe sounds legit. Ill report back with some code :)

[danielwegener]

@krosenvold Point is - the modification time of the source file says absolutely nothing about its content. This would just shift the problem from "when have I build something" to "when have i touched something" - it still would not be about "what was built" (independent from time).

[sewe]

Would it make more sense to actually adjust the timestamp of the .class file to match the source file ?

That would still not always help in creating reproducible builds, as it assumes that the modification timestamp of a freshly checked out source file stays the same across checkouts, which I don't think holds for every SCM out there.

[danielwegener]

That would still not always help in creating reproducible builds, as it assumes that the modification timestamp of a freshly checked out source file stays the same across checkouts, which I don't think holds for every SCM out there.

Not for git at least. There are only commit-timestamps

[sewe]

@sewe sounds legit. Ill report back with some code :)

Great! Thank you.

[krosenvold]

Yeah, I suppose it makes sense to use something like the commit timestamp of the head commit.

[danielwegener]

Well even then, if I have different commits that change stuff that does not impact the compiler input (.java file) -> hence does not influence the compiler output (.class files), I'd still get different artifacts. I don't see any use of the modified timestamp of files within a jar (even the weird JSP template case does only make AFAIK sense If modify an exploded template in the war).
But for this component, a timestamp parameter will offer best flexibility.

[krosenvold]

As long as the change just makes it possible to set a fixed file date on the archiver level I think this is a good solution. Someone else can decide what to set :)