Le vendredi 17 avril 2020, 22:20:11 CEST Michael Osipov a écrit : > 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. that means "not reproducible", then if we're at that level, let's just not apply any timestamp calculations: it's just disabling reproducible output for SNASPHOTs
> > Please also ask on [email protected], I might have missed other use cases. good idea, thank you > > Michael > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
