Am 2020-04-17 um 22:00 schrieb [email protected]:
Reproducible Builds is now implemented in many plugins: it's time to work on
reproducible war files.
I created MWAR-432 issue and implemented classical Reproducible jar output in
corresponding branch.
But in our discussion in november [1], an issue was reported for unchanged
timestamp in SNAPSHOTs war regarding Tomcat detection algorithm of changed
content.
If you are referring to Tomcat's ETag calculation, it uses both
timestamp and file size. The weak ETag will change as soon as the fize
size changes. Of course, this is a problem because if the file changes,
but the content length does not, the ETag won't.
From a Tomcat perspective this does not matter because every deployment
has its own class loader and in-memory cache.
From a client's one, yes. The client will receive a 304 and read from
cache although the file has been changed.
Should we just disable reproducible wars for SNAPSHOTs and enable it only for
releases?
Should we add a boolean option for people to decide whether they want
reproducible SNAPSHOTs?
It should be a user choice.
Is there any idea on how we could manage output timestamp for SNAPSHOTs?
You could do baselining:
* All files which have been changed before output timestamp, will have
output timestamp
* All other files will retain their timestamp.
A changed file will be immediately reflected by its new timestamp.
Please also ask on [email protected], I might have missed other use cases.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
