I think this can be easily solved by adding an optional input for the java version?

• https://docs.github.com/en/actions/using-workflows/reusing-workflows#using-inputs-and-secrets-in-a-reusable-workflow

Looks it was considered already #5

Perhaps a version v2 of workflows should be sufficient

Opened #31 with a default JAVA_MAJOR_VERSION input set to "11" by default that can easily be set to "17" by plugin maintainers until we switch this default value to "17" when controllers will require JDK17.

This should circumvent the need for a v2.

WDYT?

As suggested by @jglick in #31 (comment), I changed the scope of my pull request to directly update Java to 17:

you should be able to build any plugin using JDK 17. The POM will effectively pass -release 11 to tools. In fact most Jenkinsfiles do not use JDK 11 at all any more (only 17 & 21), and for purposes of the CD release workflow it is even less important to run on the older JDK because the only reason to include JDK 11 in Jenkinsfile would be to run tests on 11 (in case there is some subtle behavioral difference) yet the CD workflow skips all tests.

I'll post that in the original jenkinsci-dev mailing list thread at https://groups.google.com/g/jenkinsci-dev/c/11P2B9s67tw/m/buquLnLeAwAJ for additional reviews and see if there is any objection.