Steps towards reproducible builds

[tonygermano]

I recommend looking at the commits individually. See commit messages for details.

After these changes, the only files that remain different in the setup folder between two consecutive builds are mirth-client-core.jar, due to the version.properties file which still contains the build timestamp. I did not want to tackle that one in this same PR since it will require code changes, as that value is used in a ConfigurationController API method.

Edit: Here are the commit messages for each commit after the most recent push

commit cae3da4
Author: Tony Germano tony@germano.name
Date: Thu Jan 1 00:38:59 2026 -0500

Build: Archives to use modified time of last commit

Previously all class files and resources were added to the built jars
with the build time. With this change the jar, war, and zip tasks will
use the time stamp from the HEAD commit as the modified times of the
entries in order to work towards reproducable builds.

If unable to get the modified time of the last commit, the value will
default to the timestamp of when the openintegrationengine.org domain
was registered.

commit ab34440
Author: Tony Germano tony@germano.name
Date: Thu Jan 1 23:46:40 2026 -0500

Build: Inject git version in Javadocs and improve reproducibility

This patch updates the Ant build process to include Git versioning
information in the generated Javadocs and ensures the build remains
robust in environments without Git.

Changes include:
- Implemented a new `exec-with-default` macro in `mirth-build.xml`. This
  safely attempts to retrieve the Git hash and version name but falls
  back to default values ("unknown") if the `.git` directory is missing
  (e.g., source tarballs) or Git is not installed.
- Updated the Javadoc target to inject a footer containing the build
  version.
- Added conditional logic to render a hyperlink to the GitHub commit
  only if the revision is available; otherwise, it renders plain text.
- Added the `-notimestamp` flag to the Javadoc task to support
  reproducible builds (ensuring identical output for identical input).
- Refactored argument passing (switched from `line` to `value`) and
  added proper Ant namespaces for conditional execution.

commit 63dfe1f
Author: Tony Germano tony@germano.name
Date: Tue Jan 6 01:51:48 2026 -0500

Build: Move defaults for detected build properties

The default values for the following properties are now specified in the
.properties files in the event that git is unavailable when building the
project:

- git.commit.timestamp
- git.commit.hash
- git.commit.name

The default properties have the same names as the properties above with a
`.default` suffix.

commit 7c6f617
Author: Tony Germano tony@germano.name
Date: Tue Jan 6 02:00:25 2026 -0500

Build: Add ignoreDirtyWorkTree property

Setting the value of this property to true will omit the `--dirty` flag
to `git describe` when generating the `git.commit.name`. This is helpful
when comparing the build output to a previous build after making an
uncommited change.

commit bfd8064
Author: Tony Germano tony@germano.name
Date: Tue Jan 6 01:11:54 2026 -0500

Build: Workflow performs partial clone

Set checkout action options to perform a partial clone that omits all
blob objects (files) and trees except for those that belong to the head
commit. All commit objects and tags will be downloaded to allow `git
describe` to work in the CI environment.

[tonygermano]

The bottom text on the javadoc pages looks like this:

• The commit links to ab34440
• The license links to https://www.mozilla.org/MPL/2.0/

[mgaffigan]

Can we get a more obviously "false" value? 2000-01-01 00:00:00 or 2099-12-31 00:00:00 come to mind.

Git seems a safe build dependency, and handling its absence seems likely to silently break over time. Let's make it required, with a fallback that the values can be passed explicitly. (Call git if the value is not set, but an error is an error).

[tonygermano]

Can we get a more obviously "false" value? 2000-01-01 00:00:00 or 2099-12-31 00:00:00 come to mind.

Git seems a safe build dependency, and handling its absence seems likely to silently break over time. Let's make it required, with a fallback that the values can be passed explicitly. (Call git if the value is not set, but an error is an error).

With this PR, normally the first thing the build echoes out looks like this:

     [echo] Using git.commit.timestamp of [2026-01-06T07:13:14Z]
     [echo] Using git.commit.hash of [c9ae71a776d25857634bf80028c276593736661f]
     [echo] Using git.commit.name of [v4.5.2-52-gc9ae71a]

When the git calls fail it looks like:

     [exec] Result: 1
     [echo] Using git.commit.timestamp of [2025-03-25T22:28:08.664Z]
     [exec] Result: 1
     [echo] Using git.commit.hash of []
     [exec] Result: 1
     [echo] Using git.commit.name of [unavailable]

If git isn't present (like if someone unpacked a sources.tar.gz,) then it makes sense to default back to some other values to allow the build to continue without failing, because these values are only metadata. Originally, I had the default timestamp set to unix epoch, but it turns out that the zip structure is based on the 16-bit FAT filesystem, and doesn't support dates that early. Since I was picking an arbitrary date, I made it related to the project, but it's not necessarily a failure condition (I intentionally set failonerror="false".) I figured if anyone was checking the date closely, cared about the value, and missed the build output above, a date from March 2025 would still throw up some flags considering it is now 2026.

I pushed a change that moves the default values for when git is unavailable to the build.properties files instead of hard coding them in the build.xml files. For now, I don't think we need to consider git as a requirement to build. If something changes down the road where it becomes an actual requirement I will reconsider my opinion on hard failing when it's not available.

Since ant properties are immutable, the actual properties (git.commit.timestamp instead of git.commit.timestamp.default) can be added to build.properties or passed like -Dgit.commit.timestamp=2000-01-01T00:00:00Z to override what git would set, even when it is available.

The description of this PR has been edited to include all of the commit messages for the original and additional commits.

[mgaffigan]

If git isn't present (like if someone unpacked a sources.tar.gz,) then it makes sense to default back to some other values to allow the build to continue without failing, because these values are only metadata.

Fine, make it fail gracefully, but use the current date - not some fixed default.

I figured if anyone was checking the date closely, cared about the value, and missed the build output above, a date from March 2025 would still throw up some flags considering it is now 2026.

I don't know what environments you work in, but a random second in 2023 is an unremarkable date. A fair number of systems I work with still start with 201X. I only killed the 1990's in 2016. I'm worried about the ops folks in 2030, not someone who has access to build output.

I have no problem with

• 2023-01-01 00:00:00
• 2023-04-05 06:07:08
• or any other value with low entropy