Hi Mark, It is possible to use jdk.javadoc/jdk.compiler as libs and plug in through the Context class forcing a JavaFileManager to force a DocFileFactory in the HtmlConfiguration but it will be way more complex than unzipping/rezipping the jar. Another option can be a light javaagent patching the few classes you want. Also wonder if you tried -notimestamp option.
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 mar. 18 janv. 2022 à 23:34, Christopher Schultz < ch...@christopherschultz.net> a écrit : > Mark, > > On 1/18/22 15:03, Mark Thomas wrote: > > On 18/01/2022 19:39, Mark Thomas wrote: > > > > <snip/> > > > >> The first issue looks relatively simple to fix. I don't see an easy > >> fix for the second. My best idea so far is some sort of > >> post-processing for the Javadoc generation that extracts the file from > >> the zip, sets the timestamp and then re-zips it. Suggestions for a > >> better solution welcome. > > > > Yep, I think I fixed the first issue. > > > > I'm wondering about second issue. It would be nice to have a complete > > fix but if the full docs package isn't reproducible how much of an issue > > is that? > > I'm -0 on any efforts to make the javadoc builds reproducible. They > aren't exactly binary artifacts and anyone performing an audit isn't > going to treat documentation as in-scope anyways (at least not at this > point). > > Does javadoc (or ant's javadoc task) not support explicit timestamps to > use (like javac does)? I haven't looked-into how javadoc (the CLI tool) > does things lately, but I wasn't aware it produced ZIP files. Is that > javadoc itself, or is that some ant post-processing step? If it's ant, > can't we just run <touch> on all those files before zipping them? > > -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
