Hervé, can you clarify why you mention so strongly tomcat? Just out of my head tomcat, undertow, vertx, netty, camel, all cxf transports (including standalone, talend sdk, wildfly, tomee, meecrowave, restlet, quarkus, helidon, jetty, resin, play, akka-http, xnio and much more are affected at war and jar levels so why would tomcat be specific? It is just impacting any application using timestamps of what is packaged.
To rephrase it: all impl are quite equivalent. Now, technically, a new phase in release plugin adding the timestamp (and eol?) in the pom in prepare phase works I think and is (almost) portable for the jar, war and ear packagings for users, no? I can envision an <enforceReproducible> in release plugin maybe. Am I missing something? Le sam. 18 avr. 2020 à 15:44, Hervé BOUTEMY <[email protected]> a écrit : > SNAPSHOTs and releases are similar from certain points of view and > different > from others: what interests me is that we vote on releases, which are the > only > official states we publish (as a source-release.zip tarball disconnected > from > scm), but we don't do it on SNAPSHOTs, which are only intermediate states > we > only keep on scm. > > But I understand that from a Tomcat perspective, hosting SNAPSHOTs or > releases > is quite similar. > > Perhaps this question of Reproducible Builds and the impact of fixed > timestamp > in jar/wars would be something that would require some Tomcat-specific > documentation (that perhaps other servlet containers don't implement the > same > way), that we could point to in maven-war-plugin? > > We should probably switch this discussion to Tomcat ML, users or dev. > > Regards, > > Hervé > > Le samedi 18 avril 2020, 12:34:01 CEST Romain Manni-Bucau a écrit : > > Snapshot or releases are not different until you force a pre-release step > > to hardcode the timestamp in the pom which would defeat release process > > until done in release plugin IMHO. > > Using scm meta is not that bad in that aspect. > > > > Side note: this is not a war plugin issue and affects jar plugin too > cause > > they regularly host we resources too (through standard servlet layout or > > not). > > > > So overall sounds like a transversal archiver fix and not by type to me. > > > > Le sam. 18 avr. 2020 à 12:14, Hervé BOUTEMY <[email protected]> a > > > > écrit : > > > 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-performanc > > > e > > > > > > > Le sam. 18 avr. 2020 à 10:08, Hervé BOUTEMY <[email protected]> > a > > > > > > > > écrit : > > > > > 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] > > > > > > --------------------------------------------------------------------- > > > 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] > >
