On 19/01/2022 07:47, Romain Manni-Bucau wrote:
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.
Nice idea. I hadn't thought of that. But I agree the complexity means
the unzip/rezip approach is a better option in this instance.
Another option can be a light javaagent patching the few classes you want.
Another neat idea but it think the complexity rules this out as well.
Also wonder if you tried -notimestamp option.
Already running with that option.
Romain Manni-Bucau
<snip/>
Le mar. 18 janv. 2022 à 23:34, Christopher Schultz <
ch...@christopherschultz.net> a écrit :
<snip/>
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?
It is javadoc. It creates 3 JSON index files and then zips them. The zip
files end up with the expected timestamp. It is the JSON files that get
zipped up that are the issue.
I'm still undecided whether to try and fix this or not.
I haven't got code signing working with reproducible builds yet but I
have a few ideas and will be looking at that today. I also want to look
at the results of comparing some cross-platform builds.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
