Work around JENKINS-68568 #563
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
timja
approved these changes
Jun 28, 2022
|
See #478 for the real fix. |
6 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Maven HPI plugin 3.27 or later (which is included in plugin parent POM 4.40 or later) almost allows the plugin POM to support cores that require both Java 8 and Java 11 by dynamically reconfiguring
maven.compiler.releaseandmaven.compiler.testRelease(which default to 8 in order to support cores prior to 2.357) to the version of Java thatjenkins/model/Jenkins.classwas compiled with (which could be 11 with 2.357 or later): "almost" because Enforcer's bytecode version check still gets in the way if a plugin has a baseline of 2.357 or later and has a library on its classpath with Java 11 bytecode. Unfortunately, there is no easy way for Maven HPI plugin to dynamically reconfigure Enforcer for Java 11 the same way it dynamically reconfigures Maven Compiler Plugin for Java 11. So in order for the plugin POM to support baselines before and after 2.357 and allow plugins to use Java 11 features with a baseline of 2.357 or later if so desired, we work around the problem by increasing the maximum JDK version for Enforcer to 11 below. While technically incorrect (in the sense that it fails to enforce the absence of Java 9, 10, or 11 bytecode when it should) when building, testing, or releasing a plugin with a baseline prior to 2.357 using a Java 11 compiler (including CD), any such plugin should have aJenkinsfilebuild running on Java 8, where the correct enforcement should be present, so this should not cause any practical problems. This workaround is justified because the alternative (raising the minimum Jenkins version for the plugin POM to 2.357 or later and dropping support for Java 8) would be overly harsh on users, causing Dependabot updates to fail for the majority of users who do not want to update their baseline so aggressively. When we are ready to raise the minimum Jenkins version for the plugin POM to 2.357 or later and drop support for Java 8, this workaround can be deleted.Testing done
Ran
mvn clean verify -Djenkins.version=2.357 -Djgit.version=6.2.0.202206071550-r -DskipTestsingit-clientbefore and after this PR, with Java 11. Before this PR, trying to compile with 2.357 and JGit should have worked, because the core is new enough to support Java 11; however, it failed the Enforcer check as expected. After this PR, it passed the Enforcer check as expected.