Remove hard-coded Java version in security scan

[basil]

Hard-coding Java 11 is a bad idea since we plan to EOL it in the next few months.

[basil]

@strangelookingnerd A number of these YML files are inconsistent. Can you please normalize them to avoid hard-coding a Java version in any of these YML files:

apache-httpcomponents-client-4-api-plugin
      java-version: 21 # What version of Java to set up for the build.
--
asm-api-plugin
      java-version: 11 # What version of Java to set up for the build.
--
authentication-tokens-plugin
      java-version: 21 # What version of Java to set up for the build.
--
blueocean-plugin
      java-version: 21 # What version of Java to set up for the build.
--
branch-api-plugin
      java-version: 21 # What version of Java to set up for the build.
--
cloudbees-folder-plugin
      java-version: 21 # What version of Java to set up for the build.
--
commons-lang3-api-plugin
      java-version: 11
--
commons-text-api-plugin
      java-version: 11
--
configuration-as-code-plugin
      java-version: 21 # What version of Java to set up for the build.
--
credentials-plugin
      java-version: 17 # What version of Java to set up for the build.
--
dashboard-view-plugin
      java-version: 17  # What version of Java to set up for the build.
--
docker-workflow-plugin
      java-version: 21 # What version of Java to set up for the build.
--
eddsa-api-plugin
      java-version: 11 # What version of Java to set up for the build.
--
favorite-plugin
      java-version: 17 # What version of Java to set up for the build.
--
git-client-plugin
      java-version: 21 # What version of Java to set up for the build.
--
git-plugin
      java-version: 21 # What version of Java to set up for the build.
--
git-server-plugin
      java-version: 17 # What version of Java to set up for the build.
--
gson-api-plugin
      java-version: 11 # What version of Java to set up for the build.
--
htmlpublisher-plugin
      java-version: 17 # What version of Java to set up for the build.
--
instance-identity-plugin
      java-version: 17 # What version of Java to set up for the build.
--
javadoc-plugin
      java-version: 21 # What version of Java to set up for the build.
--
joda-time-api-plugin
      java-version: 11 # What version of Java to set up for the build.
--
json-api-plugin
      java-version: 11 # What version of Java to set up for the build.
--
json-path-api-plugin
      java-version: 11 # What version of Java to set up for the build.
--
junit-plugin
      java-version: 21 # What version of Java to set up for the build.
--
kubernetes-credentials-plugin
      java-version: 21 # What version of Java to set up for the build.
--
kubernetes-plugin
      java-version: 21 # What version of Java to set up for the build.
--
mailer-plugin
      java-version: 17 # What version of Java to set up for the build.
--
matrix-project-plugin
      java-version: 17 # What version of Java to set up for the build.
--
metrics-plugin
      java-version: 21 # What version of Java to set up for the build.
--
oauth-credentials-plugin
      java-version: 21 # What version of Java to set up for the build.
--
pipeline-input-step-plugin
      java-version: 21 # What version of Java to set up for the build.
--
pipeline-maven-plugin
      java-version: 11 # What version of Java to set up for the build.
--
saml-plugin
      java-version: 11 # What version of Java to set up for the build.
--
ssh-agent-plugin
      java-version: 11
--
ssh-agents-plugin
      java-version: 17 # What version of Java to set up for the build.
--
support-core-plugin
      java-version: 17 # What version of Java to set up for the build.
--
token-macro-plugin
      java-version: 17 # What version of Java to set up for the build.
--
view-job-filters-plugin
      java-version: 17 # What version of Java to set up for the build.
--
workflow-api-plugin
      java-version: 21 # What version of Java to set up for the build.
--
workflow-job-plugin
      java-version: 21 # What version of Java to set up for the build.

[strangelookingnerd]

@strangelookingnerd A number of these YML files are inconsistent. Can you please normalize them to avoid hard-coding a Java version in any of these YML files:

I will look into it. My template uses the default, however I left the property and its description in place (commented-out). I thought this allows maintainers to change it more easily without consulting the documentation first.
I downgraded some builds because they simply did not run with Java 17 / 21.

[basil]

This build obviously didn't need Java 11 to be hard-coded and I suspect almost all of the above are the same. I agree that it is nice to leave the defaults commented out to allow for customization. When there is a customization, the reason for the customization can be provided in a comment. A customization without a reason should not be retained.

[jonesbusy]

Thanks for your PR.

I wanted to open a PR on https://github.com/jenkinsci/plugin-modernizer-tool to perform the cleanup (The GSoC 2024 project on openrewrite)

But it looks there is a bug on the original recipe to comment out a YAML property

openrewrite/rewrite#4392

[basil]

Thank you very much! I have merged the PRs for critical plugins. If I have time I will try to go through the remaining long-tail plugins as well.

[a-zitzewitz]

For the Sonargraph Plugin, if I remove the Java version it defaults to Java 8 and that does not work. Higher Java versions should be ok...