Install a specific version of Maven

[jonesbusy]

This fixes occurrence of

[ERROR] The build could not read 1 project -> [Help 1]
org.apache.maven.project.ProjectBuildingException: Some problems were encountered while processing the POMs:
[ERROR] Unknown packaging: hpi @ io.jenkins.plugins:flyway-api:${revision}-${changelist}, /home/runner/work/flyway-api-plugin/flyway-api-plugin/pom.xml, line 13, column 14
at org.apache.maven.project.DefaultProjectBuilder.build (DefaultProjectBuilder.java:397)
at org.apache.maven.graph.DefaultGraphBuilder.collectProjects (DefaultGraphBuilder.java:414)

Seen in https://github.com/jenkinsci/flyway-api-plugin/pull/78/checks for example

Confirmed this work by running this adapted workflow on https://github.com/jenkinsci/flyway-api-plugin/pull/99/checks

Except the maven version upgrade, the rest remain outouched

Possible caused by recent changes https://github.com/jenkinsci/maven-hpi-plugin ?

I can easily reproduce locally with Maven 3.8.8.

[daniel-beck]

jenkinsci/maven-hpi-plugin#668 is another reason to ensure a recent Maven.

[basil]

See actions/setup-java#685 (a different fix for the same issue) for comparison. I am not implying that one solution is better or worse than another, but rather I am mentioning the alternative for completeness.

[jonesbusy]

See actions/setup-java#685 (a different fix for the same issue) for comparison. I am not implying that one solution is better or worse than another, but rather I am mentioning the alternative for completeness.

Thanks I saw also this page. To be honest I don't have a strong opinion about the approach. As long is consistent across Jenkins reusable workflows

I just choose this action s4u/setup-maven-action because it looks well maintained, and less code to maintains on the workflow

Let me know and I can adapt the PR with the choose approach

[daniel-beck]

It's unclear what the benefit of s4u/setup-maven-action is compared to stCarolas/setup-maven (which it uses internally).

If we're not doing the download manually ourselves, having a smaller dependency seems better.

If we want consistency between workflows, I'll defer to the CD workflow maintainers, that's the more important one.

[jonesbusy]

Once decided I will update this PR with the choose approach

[basil]

jenkins-infra/github-reusable-workflows#37 was merged, so can we update this PR to match for consistency?

[jonesbusy]

Sure I will update tomorrow by doing the maven download instead of composite action

[jonesbusy]

I've applied the same change here.

Ensured the maven version is correct by running test workflow here https://github.com/jenkinsci/flyway-api-plugin/pull/109/checks

[basil]

Currently blocking jenkinsci/workflow-job-plugin#471

[timja]

Released as https://github.com/jenkins-infra/jenkins-security-scan/releases/tag/v2

[basil]

Thank you very much!