keeping SNAPSHOTs reproducible with calculated value for timestamp is an option that can be chosen by some people assuming SNAPSHOTs are not reproducible seems a reasonable option: requirement for reproducible SNAPSHOTs is really different from requirement for releases
IMHO, the misc strategies available for war files, against the way some web servers use timestamp, will require dedicated documentation in maven-war- plugin and one key war-specific feature: disable reproducible output for SNAPSHOTs, which is one strategy that can be chosen (Jira issue yet to be created) Will require help from others to write this doc before the maven-war-plugin release. Regards, Hervé Le samedi 18 avril 2020, 10:30:21 CEST Romain Manni-Bucau a écrit : > Hi everyone, > > I got the same issue for my current work webapps (not at archive level but > docker image level - I'm using jib and it enforces a "constant" timestamp). > I solved it by using last commit timestamp as file timestamp. Indeed it can > miss a "strict" cache hit but globally it is a good compromise and guess it > can be reused for reproducible builds. > In any case, a project using a scm will be reproducible only regarding a > commit so it sounds like the least bad compromise. > wdyt? > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> > | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > Le sam. 18 avr. 2020 à 10:08, Hervé BOUTEMY <herve.bout...@free.fr> a > > écrit : > > Le vendredi 17 avril 2020, 22:20:11 CEST Michael Osipov a écrit : > > > Am 2020-04-17 um 22:00 schrieb herve.bout...@free.fr: > > > > 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 users@tomcat.a.o, I might have missed other use > > > > cases. > > good idea, thank you > > > > > Michael > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
