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

Reply via email to