[oscerd]

Addresses two of the three items in #731.

1. Pin the third-party action

EnricoMi/publish-unit-test-result-action@v2 -> @d0a4676d0e0b938bc201470d88276b7c74c712b3 # v2.24.0

v2 is a mutable tag on a non-GitHub-authored action. It runs with
if: always() on push and pull_request under checks: write, after the
shared Maven cache is restored and before its post-step saves it. A force-moved
tag changes what executes with no change landing in this repository, and
Dependabot cannot detect a tag that moves under it. Dependabot can still bump
the pinned SHA, which is the usual Apache infra arrangement.

The SHA is the commit v2 currently resolves to, which is the v2.24.0
release.

2. Activate the checksum verification that already exists

mvnw:254-281 and the wrapper jar both implement SHA-256 verification, but
the code was dormant because neither wrapperSha256Sum nor
distributionSha256Sum was set. Setting them turns the project's own existing
mechanism on.

wrapperSha256Sum is worth having even though the jar is committed: mvnw
validates it against the local maven-wrapper.jar, so it covers tampering
with the 62 KB of opaque bytes in the repository, which no diff can show.

Values were verified before pinning, not just computed:

• the committed .mvn/wrapper/maven-wrapper.jar is byte-identical to
  maven-wrapper-3.2.0.jar on Maven Central
  (e63a53cf…f52f066a) -- so this pins a known-good jar, not whatever happened
  to be in the tree
• apache-maven-3.9.6-bin.zip fetched from Central has SHA-512 matching the
  value published at downloads.apache.org/maven/maven-3/3.9.6/binaries/
  exactly, so the SHA-256 recorded here (83aaf914…c031625f) is the ASF
  artifact

Both were then confirmed to actually enforce, by corrupting each sum in turn:

# corrupted wrapperSha256Sum
Error: Failed to validate Maven wrapper SHA-256, your Maven wrapper might be compromised.

# corrupted distributionSha256Sum, with a clean MAVEN_USER_HOME to force re-download
Exception in thread "main" java.lang.RuntimeException: Failed to validate Maven
distribution SHA-256, your Maven distribution might be compromised.

and ./mvnw -v runs normally with the committed values, both from cache and
from a fresh download.

3. Not done: removing the root <repositories> block

#731 also proposed dropping the Atlassian repository from the root POM on the
grounds that components/camel-jira/pom.xml already declares it for the only
artifacts that need it. That is not correct and would break the build, so it
is left out of this PR:

• features/src/main/feature/camel-features.xml:1996-2002 references
  com.atlassian.jira:jira-rest-java-client-{core,api},
  com.atlassian.sal:sal-api, com.atlassian.event:atlassian-event and
  com.atlassian.httpclient:* as feature bundles, and the features module
  runs karaf-maven-plugin:verify, so it has to resolve them.
• features/pom.xml does not declare the Atlassian repository -- it
  inherits it from the root.
• None of those artifacts are on Maven Central (all 404), so there is no
  fallback.

The narrower change that would achieve the original intent is to move the
declaration down to the two modules that actually need it (components/camel-jira,
which already has it, plus features) rather than delete it. I have not done
that here because it wants a full reactor build to confirm nothing else in the
tree resolves an Atlassian coordinate, and that is a separate change from the
two above. Details are in #731.

Notes

No functional change to the build; CI on this PR exercises the pinned action.

---

Claude Code on behalf of Andrea Cosentino