Mark,
On 10/18/23 11:43, Mark Thomas wrote:
On 18/10/2023 15:06, Konstantin Kolinko wrote:
ср, 18 окт. 2023 г. в 14:55, Mark Thomas <ma...@apache.org>:
On 17/10/2023 16:36, Mark Thomas wrote:
It looks like Javadoc generation is different between Linux and Windows
with Java 21. That is still causing issues for the full-docs package
for
Tomcat 11. I'm still looking into options for fixing that. Other than
that, I'm not seeing any reproducibility issues for those files.
I've got as far as figuring out what is causing the problem.
This commit
https://github.com/openjdk/jdk/commit/e9f3e325c274f19b0f6eceea2367708e3be689e9
causes the files from $JAVA_HOME/legal/jdk.javadoc to be added to the
legal directory in the created javadoc. In Linux, some of those files
are symlinks so the entire file gets copied whereas in Windows some of
those files are text files that reference the symlink target.
I am currently leaning towards writing an Ant task that will replace
those "link" files on Windows with the target of the link. It will need
to run after the Javadoc.
Maybe this will be fixed in JDK itself?
It looks like it should be.
Essentially their fix for "8259530" (the commit that you referenced)
is incomplete on Windows,
and that is a legal issue.
+1
BTW, Reviewing that commit, I see that there exists a command-line
option, "--legal-notices" that can be set to "none".
BTW, the files can be seen in apache-tomcat-11.0.0-M13-fulldocs.tar.gz
e.g. \tomcat-11.0-doc\api\legal\LICENSE is the following one nonsense
line:
Please see ..\java.base\LICENSE
So, do we try and fix this to get back to completely reproducible builds
or do we accept that the full-docs package isn't reproducible until this
bug gets fixed?
Given this is just the full-docs, I'm leaning towards raising an OpenJDK
bug and accepting that the full-docs package won;t be 100% reproducible
at the moment.
+1
In the "verify-release" ant target, I'm already ignoring the fulldocs
artifact, though I am /checking/ it before ignoring the result.
But Mark, if you missed my message from the 13th, you'll see that the
problem is I'm running a slightly different version of Java than you
are, and the exact spelling of the version string is causing the problem
-- mostly in MANIFEST.MF files because the whole JRE's version string is
present in there and not just the version number.
A recent commit of mine adds the release version number (only) to the
build.properties.release file so it can be checked for a match in
verify-release. I wonder if we should check the full version string to
ensure the verifier and releaser are using the exact same versions.
That's really the only way to prevent someone from attempting to verify
a release and claiming it's not reproducible for not-relevant reasons.
And I'd very much like to make it next-to-trivial for anyone to verify a
release build.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
