Make the build reproducible by deriving version metadata from the manifest

[ppkarwasz]

VersionInfo was the last part of the build that could not produce the same output twice.

saveVersion.sh (and its PowerShell twin) generated a @VersionAnnotation at generate-sources recording the builder's user name, host name, working directory, wall clock and an MD5 of every *.java file in the tree. Six of the seven fields were therefore machine-specific, and the source distribution generated by logging-parent carries no repository metadata at all, so a build from it could never match a build from a Git checkout.

The same facts now come from manifest headers derived from the POM, so a Git checkout and the source archive produce byte-identical artifacts.

Manifest

Three headers are appended to the BND-generated manifest through bnd-extra-config, which puts them in target/classes as well as the JAR, so the values are also available to tests and in the IDE:

Header	Source	Specified by
Bundle-SCM	<scm>	OSGi Core R8, section 3.2.1
Implementation-Timestamp	project.build.outputTimestamp	nothing, see below
Purl	groupId, artifactId, version	the value follows the package-url specification, the header name is ours

Neither the JAR File Specification nor OSGi defines a header for a build timestamp or a package identifier, so those two are Flume-specific. Implementation-Vendor-Id was considered for the latter and rejected: it is deprecated in java.util.jar.Attributes.Name as a leftover of the extension mechanism removed by JEP 220.

VersionInfo

Method	Source
getVersion()	Implementation-Version, then pom.properties
getPurl() (new)	Purl, then built from pom.properties
getUrl()	Bundle-SCM attribute url
getBranch()	Bundle-SCM attribute tag
getDate()	Implementation-Timestamp
getRevision()	fixed, until the build records a commit id again
getUser(), getSrcChecksum()	fixed, deprecated for removal

The manifest is resolved against the location of VersionInfo.class rather than looked up on the class path, so another artifact cannot answer, and it is accepted only when its Purl identifies flume-ng-core. When Flume has been shaded into an uber JAR the manifest belongs to the shading project, so it is rejected and META-INF/maven/org.apache.flume/flume-ng-core/pom.properties is used instead.

VersionAnnotation, both saveVersion scripts and the two OS-conditional profiles that ran them are removed.

Also fixed

flume-parent, which is the parent of every published module, never received the revision and project.build.outputTimestamp conventions applied to the aggregator in #467. It still carried a 2022 timestamp and a hard-coded version, and since the release automation patches only the root POM, neither would have been updated at release time. The first commit applies the convention there and switches all child modules to ${revision}.

Verification

• Two clean builds of flume-ng-core produce the same SHA-256.
• flume-ng version prints identical output from the JAR and from target/classes.
• The shaded fallback is exercised against a real uber JAR built with a foreign manifest.
• mvn verify is green; PMD and SpotBugs counts are unchanged.

Still open

The release workflow in logging-parent bumps revision and project.build.outputTimestamp in the root POM only, so flume-parent will go stale at release time. That needs a fix upstream.

[Copilot]

Pull request overview

Warning

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Makes Flume builds reproducible by removing machine-specific version annotation generation and instead deriving build/version metadata from Maven/BND manifest headers (with Maven descriptor fallback).

Changes:

• Replace @VersionAnnotation + saveVersion.* scripts with manifest/pom.properties based metadata lookup in VersionInfo.
• Standardize module versions on ${revision} and update flume-parent properties (incl. project.build.outputTimestamp) for reproducible output.
• Expand VersionInfo unit tests to cover manifest preference, fallbacks, and SCM header parsing.

Reviewed changes

Copilot reviewed 29 out of 29 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
flume-tools/pom.xml	Switches parent version to ${revision} for CI-friendly versioning.
flume-parent/pom.xml	Introduces ${revision}, updates SCM tag, sets reproducible timestamp, and appends manifest headers via bnd-extra-config.
flume-ng-sources/pom.xml	Switches parent version to ${revision}.
flume-ng-sources/flume-taildir-source/pom.xml	Switches parent version to ${revision}.
flume-ng-sources/flume-syslog-source/pom.xml	Switches parent version to ${revision}.
flume-ng-sources/flume-netcat-source/pom.xml	Switches parent version to ${revision}.
flume-ng-sources/flume-http-source/pom.xml	Switches parent version to ${revision}.
flume-ng-sdk/pom.xml	Switches parent version to ${revision} and customizes test-jar manifest to avoid inheriting the main bundle’s manifest metadata.
flume-ng-node/pom.xml	Switches parent version to ${revision}.
flume-ng-instrumentation/pom.xml	Switches parent version to ${revision}.
flume-ng-instrumentation/flume-prometheus-monitor/pom.xml	Switches parent version to ${revision}.
flume-ng-instrumentation/flume-http-monitor/pom.xml	Switches parent version to ${revision}.
flume-ng-instrumentation/flume-ganglia-monitor/pom.xml	Switches parent version to ${revision}.
flume-ng-dist/pom.xml	Switches parent version to ${revision}.
flume-ng-core/src/test/java/org/apache/flume/tools/TestVersionInfo.java	Reworks tests to validate new manifest/pom.properties metadata resolution and SCM header parsing.
flume-ng-core/src/main/java/org/apache/flume/tools/VersionInfo.java	Reimplements version metadata resolution via manifest headers (with pom.properties fallback) and removes dependency on generated package annotation.
flume-ng-core/src/main/java/org/apache/flume/VersionAnnotation.java	Removes the now-unneeded build-time annotation API.
flume-ng-core/scripts/saveVersion.sh	Removes unreproducible, machine-specific version generation script.
flume-ng-core/scripts/saveVersion.ps1	Removes unreproducible, machine-specific version generation script.
flume-ng-core/pom.xml	Removes OS-conditional profiles that generated VersionAnnotation sources; switches parent version to ${revision}.
flume-ng-configuration/pom.xml	Switches parent version to ${revision}.
flume-ng-configfilters/pom.xml	Switches parent version to ${revision}.
flume-ng-configfilters/flume-ng-external-process-config-filter/pom.xml	Switches parent version to ${revision}.
flume-ng-configfilters/flume-ng-environment-variable-config-filter/pom.xml	Switches parent version to ${revision}.
flume-ng-configfilters/flume-ng-config-filter-api/pom.xml	Switches parent version to ${revision}.
flume-ng-channels/pom.xml	Switches parent version to ${revision}.
flume-ng-channels/flume-spillable-memory-channel/pom.xml	Switches parent version to ${revision}.
flume-ng-channels/flume-file-channel/pom.xml	Switches parent version to ${revision}.
flume-ng-auth/pom.xml	Switches parent version to ${revision}.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[ppkarwasz]

I merged this to fix the reproducibility check, but I am open to follow-up PRs if this requires refinement.