On 22/03/2022 19:06, Christopher Schultz wrote:
On 3/22/22 13:12, Mark Thomas wrote:
<snip/>
The JSign Ant task that adds the detached signature doesn't close the
signed file. This causes problems for Ant. I've opened a JSign issue
[2] for this. I have a locally build version with a hack that fixes
the issue so I can continue testing.
Do you mean it doesn't call OutputStream.close()? Shouldn't that be
cleaned up when the process exits?
Effectively, yes. The problem is that the Ant task runs in process so
the file is still open when the next Ant target tries to work with the
file. You won't notice the issue running JSign from the command line.
<snip/>
If it were just the full docs package, I don't think I'd worry too
much about the Javadoc issue but the Windows installer is more of a
problem. Therefore, I plan to work on a custom Ant task that will fix
these zip files by setting the timestamps on the compressed files to
be the same as the timestamp used by the rest of the build.
Can <touch> not be used to do this?
No. The Javadoc task generates a file then zips it. We need to change
the timestamp of the file(s) inside the created zip.
<snip/>
- anyone can build a release from the tag and will get a build that
includes a signed Windows installer
Oh, that last part is clever, which of course is the whole point of the
detached signatures.
When it is finally working it is going to be really nice. We'll
effectively have a way for anyone to build from source and confirm that
they have exactly the same bits as the official release. If provides a
great way to demonstrate that the RM hasn't tampered with the binaries.
<snip/>
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.
<snip/>
The release-build should probably auto-generate a report of the
build-chain used to build the release.
Nice idea.
Other potential improvements to the build process I've been considering
making:
1. $ ant prep-release
Generates a new build.properties file, build-release.properties which
contains a few useful items:
ant.tstamp.now=[timestamp to be used for repeatable build]
version.suffix= (intentionally blank)
release.asfuser=[username of the user rolling the release]
release.jdk=[details of build environment, perhaps additional items]
release.os=[ibid]
Then modify the build script to include build-release.properties before
any others and ignore the file if it's missing.
Also this will generate res/maven/build-release.properties which will
include:
asf.ldap.username
maven.asf.release.deploy.version
gpg.exec
There's no reason these items can't be computed from the outer build
process and used inside there. It eliminates a few steps for the person
doing the release.
2. Re-name res/maven/mvn-pub.xml -> build.xml
This saves unnecessary typing during the release. I'll probably actually
move the file, then create a new one in its place pointing to the new
one, in case some other downstream process needs that file to be in-place.
I doubt that will be necessary. The file is very specific to how the ASF
is set up.
3. Read build-release.properties in build.xml (nee mvn-pub.xml) as well
as build.properties and build.properties.default. build.properties
should be almost unnecessary at this point.
4. Document the mail build <target>s in build.xml (nee mvn-pub.xml)
I'm sure there are other things I've been thinking of. These are the
ones I have in the front of my mind.
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).
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
