apache-ant

Overview

Apache Ant is a Java-based build tool used to describe and run build steps from XML build files. Its main role is to automate project builds, but it can also drive other repeatable tasks that fit a target-and-task workflow. The upstream project describes Ant as a cross-platform build tool with a large set of built-in tasks and support for custom tasks written in Java. (ant.apache.org)

In a Linux distribution, this package usually exists to provide a packaged, policy-compliant copy of Ant for software builds, packaging workflows, and other reproducible automation tasks. NiceOS maintainers should verify any distribution-specific integration points in the spec before relying on them.

Purpose and typical use cases

Typical use cases include:

• building Java applications from build.xml files;
• running compile, assemble, test, documentation, and packaging steps;
• executing repeatable project tasks in CI/CD pipelines;
• supporting projects that still use Ant-based build logic, including some non-Java workflows;
• using Ant together with other tooling when a project needs scripted build orchestration. (ant.apache.org)

Typical users include:

• package maintainers who need to rebuild upstream software that depends on Ant;
• Java developers working with legacy or established Ant build files;
• CI/CD maintainers who run deterministic build jobs;
• build and release engineers who need a scripted task runner;
• occasionally administrators who package or reproduce application builds.

Upstream project

Upstream: Apache Ant, part of the Apache Software Foundation. The project documentation describes Ant build files as XML files with projects, targets, and tasks. The manual also documents the task catalog and the user guide for writing and running build files. (ant.apache.org)

This package should be treated as a distribution build of that upstream project. If NiceOS adds downstream patches, wrappers, or policy adjustments, those changes belong in the spec and should be reviewed during updates.

Dist-git repository contents

This dist-git repository contains the packaging metadata for the RPM, not the full upstream source tree.

Expected top-level layout:

• SPECS/ — RPM spec files and packaging logic;
• SOURCES/ — source metadata and integrity manifests used to describe the upstream inputs;
• METADATA/ — repository metadata used by the packaging workflow;
• SBOM/ — software bill of materials data, when maintained for this package.

Large upstream source archives are intentionally not stored in this Git repository. Instead, the repository keeps the manifests and metadata needed to fetch and verify the sources during build preparation.

Source storage and integrity policy

Source integrity is tracked through manifest files in SOURCES/. The exact manifest format may vary by package and repository policy, but the intended model is the same: the repository records which upstream inputs are expected, while the actual large archives remain outside Git.

When updating the package, NiceOS maintainers should verify that:

• the manifest entries still match the upstream release being imported;
• the source set is complete and still corresponds to the spec file expectations;
• no unexpected files were added, removed, or renamed in the upstream tarball or build inputs;
• any downstream patches still apply cleanly after source changes.

Do not assume that a successful source fetch alone is enough; the manifests and spec should be reviewed together.

NiceOS maintenance notes

Before updating this package, check the following:

• whether the upstream release changes any build behavior, supported runtime assumptions, or task semantics that affect packaged consumers;
• whether the spec file needs patch refreshes, macro adjustments, or dependency review;
• whether SOURCES/ manifests need regeneration after source changes;
• whether SBOM/ content, if present, needs to be refreshed to stay aligned with the packaged inputs;
• whether any distribution-specific file paths, scriptlets, or configuration defaults still make sense;
• whether the update introduces changes that affect existing build scripts that rely on Ant behavior.

Risks to consider:

• build failures caused by upstream build logic changes;
• downstream patch drift;
• changes in Java runtime expectations that affect packaging in NiceOS;
• accidental mismatch between spec expectations and the source manifests;
• unreviewed changes in bundled documentation or auxiliary files.

If any of these points are unclear, NiceOS maintainers should verify them before publishing the update.

Build and verification checklist

For an RPM maintainer, a practical update checklist is:

1. Review upstream release notes and manual changes relevant to build behavior. (ant.apache.org)
2. Verify the spec still points to the correct source set and patch series.
3. Regenerate SOURCES/ manifests if the upstream source inputs changed.
4. Confirm that packaging macros, file lists, and scriptlets still match the packaged layout.
5. Rebuild the SRPM and RPMs in a clean environment.
6. Check install, upgrade, and file ownership behavior.
7. Run the package’s basic functional checks, such as invoking the Ant executable or validating the packaged library entry points, if applicable.
8. Compare the produced SBOM and metadata, if maintained, against the final packaged contents.
9. Confirm that no unexpected files from the upstream archive were introduced into the distribution package.

References

• Apache Ant
• Apache Ant User Manual
• Apache Ant Introduction
• Using Apache Ant
• Apache Ant Task Overview

Russian documentation

See README_RU.md.

Dist-git repository notes

• Package repository: rpms/apache-ant
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.