ant.hook: init, migrate a few packages

[tomodachi94]

Add a setup hook for Ant.
It does a few different things; I recommend reading the documentation for a full explanation.

I also migrated a few packages to demonstrate that this works in practice. Since there are many packages that use Ant in Nixpkgs, it would be impractical to do all of them at once in this PR.

For maintainers of changed packages

I migrated your package to the new pattern. If something (e.g. an assumption about your package, or something with the hook) looks wrong, please let me know.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[tomodachi94]

I removed the inline documentation to avoid duplicating content. A comment at the top of the hook now directs the user to the manual.

[TomaSajt]

This can break packages that have a call to ant inside of their build process.

e.g. the last time I encountered this situation was with rstudio, where cmake calls ant:

With this change, both cmake and ant try to override the buildPhase, and I guess ant's setup hook happens to get called earlier, thus the cmake build doesn't run. Also, since build.xml does not exist, it just errors out.

I guess we could just add dontUseAntBuild.

Personal opinion:
Hooks should not be directly included with the package they're wrapping.
I would be happier with an antHook than with ant having this default behaviour.
This would also not randomly break packages.

[tomodachi94]

This can break packages that have a call to ant inside of their build process.

Should I run nixpkgs-review on the changes and add dontUseAntBuild/dontUseAntCheck to builds that fail because of this change? Done, see below.

Hooks should not be directly included with the package they're wrapping.

Is there any consensus about whether we should include setup hooks in the packages themselves?

I'm conflicted: I agree that this can cause headaches when introducing a new hook into an existing package, but many packages do include a setup hook by default (like cmake).

[bjornfor]

Result of nixpkgs-review pr 357162 run on x86_64-linux 1

1 package blacklisted:

• nixos-install-tools

6 packages built:

• jffi
• jing
• mkgmap-splitter
• nixpkgs-manual
• openrocket
• xmloscopy

[TomaSajt]

By the way, do we need to have ant be a wrapper?
Its only job is to add antFlags to all ant calls from bash.
But will we ever want to call ant manually while we're using the hook?
Maybe there's the rare situation where there are multiple different ant build.xml files, in that case yes, it would shave down a manual variable substitution.

But my personal opinion is that, if we're not inside the magical land of hooks anymore, we shouldn't try to override how commands work.

[tomodachi94]

By the way, do we need to have ant be a wrapper?

Not necessarily. The function is there to reduce the amount of copy-paste between phases; I'm not opposed to renaming it to _ant or something similar.

The wrapper can be circumvented. Per the docs:

https://github.com/tomodachi94/nixpkgs/blob/enhance/ant/setup-hook/doc/languages-frameworks/ant.section.md#L10-L17

[bjornfor]

Maybe there's the rare situation where there are multiple different ant build.xml files, in that case yes, it would shave down a manual variable substitution.

We have that at $dayjob: build_{variantA,variantB}.xml.

[tomodachi94]

Ant itself also does that. In its GitHub repository, build.xml, check.xml, docs.xml, fetch.xml, and a handful more are present.