[JEP-236] [JENKINS-68570] Require Java 11 or newer #6083
Conversation
basil
added
the
rfe
oleg-nenashev
added
major-rfe
|
Nice, I’ve tried switching bom to Java 11 a couple of times but always hit weird test failures I didn’t manage to track down :( |
| @@ -719,7 +719,8 @@ THE SOFTWARE. | |||
| <artifactId>maven-surefire-plugin</artifactId> | |||
| <!-- Version specified in grandparent POM --> | |||
| <configuration> | |||
| <argLine>@{jacocoSurefireArgs}</argLine> | |||
| <!-- Make sure to keep the directives in test/pom.xml and war/pom.xml in sync with these. --> | |||
There was a problem hiding this comment.
Just seems to be shuffled around from a profile, but while we are here and since it is related to Java 11: would it be possible to introduce a POM property in root pom.xml to enforce that?
There was a problem hiding this comment.
The versions in core/pom.xml and test/pom.xml could be deduplicated but the version in war/pom.xml cannot be deduplicated because it is in the form of a MANIFEST.MF directive rather than command-line arguments. I am not sure the savings of 3 to 2 copies of the code is worth it.
…lugin (jenkinsci#6585) Co-authored-by: Basil Crow <me@basilcrow.com> Co-authored-by: Tim Jacomb <21194782+timja@users.noreply.github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
|
Hmm, somehow GitHub seems to have scrambled up the list of commits? (diff still looks sane) |
Seems fine to me? I can squash and force push if you think that would help somehow? Was planning to squash merge anyway. |
|
|
basil
changed the title
basil
added
the
ready-for-merge
|
I just filled out the PR template and added the |
|
I am going to dispense with the formality because I doubt anyone is going to object at this point. I still have a number of tasks on my landing checklist to do before Tuesday and delaying this further will just slow down the process for no benefit I think. |
|
Sorry for the inconvenience and thank you for helping to restore the status quo. I must admit that I have very little motivation to work on |
[JEP-236] [JENKINS-68570] Require Java 11 or newer
Testing done
Start Jenkins from scratch; accept default plugins; build Freestyle and Pipeline jobs.
Proposed changelog entries
Require Java 11 or newer.
Proposed upgrade guidelines
The official Jenkins Docker images have been based on Java 11 for many months, with Java 8 available as a fallback and Java 17 available in preview mode. Beginning with Jenkins 2.357, the Java 8 images will be retired and the Java 17 images will transition from preview to general availability (GA). Users of the official Docker images need not install or configure Java on their own, as it comes preinstalled in the Docker images.
Users of the official Jenkins OS packages for Debian, Red Hat, and SUSE Linux distributions should note that these packages are agnostic to the Java vendor. In other words, you must bring your own Java package. One straightforward way to do this is to install Java 11 from your Linux distribution, as described in on the package download site:
By virtue of not requiring any custom repositories, this is certainly the simplest method (and the one used by the Jenkins project’s packaging tests), but it does not give the user a high degree of control over the Java runtime environment. As mentioned previously, the official Jenkins Docker images use Adoptium/Eclipse Temurin (as does the Jenkins infrastructure project). Enthusiastic users may wish to install Java from Adoptium or another vendor. Adoptium recently began providing Linux installation packages, as described in a piece by George Adams. Ultimately, the choice of which Java vendor to use is your own, as long as that vendor provides Java 11 or Java 17. Refer to your chosen Java vendor for installation instructions.
Once you have installed a suitable version of Java, configuring Jenkins to use that Java runtime is easy. The most straightforward way is to configure that version of Java as the default version of Java at the operating system (OS) level:
update-alternatives --config javaalternatives --config javaupdate-alternatives --config javaAlternatively, users who do not wish to change the default version of Java can customize the
JAVA_HOMEorJENKINS_JAVA_CMDenvironment variable as part of the Jenkinssystemd(1)service unit. Refer to the Managing systemd services section of the Jenkins documentation for more information.Maintainer checklist
Before the changes are marked as
ready-for-merge:Proposed changelog entriesare accurate, human-readable, and in the imperative moodupgrade-guide-neededlabel is set and there is aProposed upgrade guidelinessection in the PR title. (example)lts-candidateto be considered (see query).