Mark,
On 3/23/22 12:18, Mark Thomas wrote:
On 23/03/2022 16:11, Christopher Schultz wrote:
??
$ ant javadoc
Dumps everything into output/dist/webapps/docs/, no ZIP files. The
"javadoc" target executes <javadoc> tasks and that's it.
What am I missing?
Look in the individual Javadoc directories. Each one has (I think) 3 zip
files that contain various indexes.
$ ant clean javascript
[...]
$ find output/dist/webapps/docs/ -name "*.zip" -o -name "*.jar"
$
I don't see those. Maybe it's my Java version?
$ java -version
openjdk version "16.0.2" 2021-07-20
OpenJDK Runtime Environment (build 16.0.2+7-67)
OpenJDK 64-Bit Server VM (build 16.0.2+7-67, mixed mode, sharing)
$ head output/dist/webapps/docs/servletapi/index.html
<!DOCTYPE HTML>
<!-- NewPage -->
<html lang="en">
<head>
<!-- Generated by javadoc (16) -->
<title>Overview (Servlet {servlet.spec.version} API Documentation -
Apache Tomcat 10.1.0-M13-dev)</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="description" content="package index">
<meta name="generator" content="javadoc/PackageIndexWriter">
<link rel="stylesheet" type="text/css" href="stylesheet.css" title="Style">
<link rel="stylesheet" type="text/css"
href="script-dir/jquery-ui.min.css" title="Style">
<link rel="stylesheet" type="text/css" href="jquery-ui.overrides.css"
title="Style">
<script type="text/javascript" src="script.js"></script>
<script type="text/javascript"
src="script-dir/jquery-3.5.1.min.js"></script>
<script type="text/javascript" src="script-dir/jquery-ui.min.js"></script>
</head>
So it's definitely using the Java 16 javadoc engine.
Hopefully, anything Java 11 or later with e.g. "-actlike 1.7" will
produce binary-identical artifacts. If not, merely stating that a
particular build was done with some exact JDK version should be enough.
Hopefully we'll be able to find a way to be reasonably flexible on
Java versions but we'll have to see.
As long as some other party who wishes to confirm the release hasn't
been tampered-with will be able to use the same toolchain, assuming
it's documented properly. This is what non-Java projects do for
repeatability. You can't get the same bytes when using gcc versus
clang, for example. Same with various versions of those things.
Same tool-chain should definitely work. But I'd still like to see how
much flexibility - if any - we have in versions of Java and Ant.
Sounds good. Anything that makes the release process easier is a good
thing (although compared to what it used to be like the current
process is a breeze).
:)
Okay, I'll try to do those in advance of the next releases.
Cool.
I'm having some trouble getting <tstamp> to give me
current-timestamp-in-seconds. I can get the ISO date just fine.
This SO answer [https://stackoverflow.com/a/25535927/276232] doesn't
seems to work out--of-the-box; I get an error about not being able to
initialize the javascript engine.
I tried the obvious pattern="sssssssssss" but I just got a bunch of
zeros followed by the seconds-in-the-current-minute. :/
I have it building the following build-release.properties file:
=== CUT ===
# These ant.tstamp properties specify the build-timestamp for repeatable
builds.
ant.tstamp.now=000000000000000041
ant.tstamp.now.iso=2022-03-23T16:48:41Z
# This is the ASF user who is the Release Manager for this release.
release.asfusername=schultz
# Set the version-suffix to "" (empty string) as this is not a
development release.
version.suffix=
# Release build environment information:
release.java.version=16.0.2
release.java.vm.name=OpenJDK 64-Bit Server VM
release.java.vm.version=16.0.2+7-67
release.os=x86_64 Mac OS X 11.5
release.default.file.encoding=UTF-8
=== CUT ===
So... almost everything I want :)
Any ideas for the "time in seconds" thing? (I may be able to get ant
working with javascript, but it requires a bunch of dependencies
including GraalVM, etc. - !!!).
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org