Develop and test your plugin for running on Java 11
Jenkins As a part of JEP-211, we request all plugins to remain compatible with Java 8 for now. But you may still need to run the tests with Java 11 so that you can verify the plugin's behavior. It is possible to pass "jvm" and extra Java properties to Maven Surefire plugin to just run tests, but it is easier to actually build & test plugins with JDK 11. Jenkins development tools have been updated to support building and testing with JDK11that:
- For non-experimental releases you should always build the plugins with java.level=8.
- As a part of JEP-211, we request all plugins to remain compatible with Java 8 for now
plugin-pom:3.29+(changelog). Versions before 3.29 contain some updates to be able to build and test your plugins using JDK 11
- Plugins will be able to compile successfully with JDK 11 if and only if Jenkins Core version (jenkins.version) is above 2.138+
- You can update Jenkinsfile to run tests with Java 11. In order to To workaround the Jenkins core requirement, a full configuration matrix may be used in buildPlugin():
- The existing "mvn hpi:run" command will not work correctly on Java 11 unless Java modules are downloaded and passed to the environment (
Jira server Jenkins JIRA serverId dd058dce-0c66-3b77-8b09-71b1d7728747 key JENKINS-54807
- If you use Mockito/PowerMock in your plugin tests, you may need to update to the recent versions with Java 11 support
tracks adding the versions to Plugin POM dependency management
Jira server Jenkins JIRA serverId dd058dce-0c66-3b77-8b09-71b1d7728747 key JENKINS-55098
- In some cases FindBugs may crash in some cases (
), workarounds may be needed
Jira server Jenkins JIRA serverId dd058dce-0c66-3b77-8b09-71b1d7728747 key JENKINS-53692
See the "Known developer tools issues" for more known issues in Plugin POM and Jenkins plugins.
an experimental plugin version specifically for Java 11
Current intermediate solution
First, please avoid doing this.
If you really think you have a case where you need it, we encourage you to come over the Jenkins developers mailing list to expose your case and see if we can find another way.
In any case, the strongly recommended way to handle this is:
Although we request all plugins to remain compatible with Java 8, in some cases it may be reasonable to release an experimental version for Java 11 early adopters.
and Jenkins Docker plugins.txt installer (e.g. "workflow-support:experimental") will default to this experimental update center. It allows Java 11 early adopters to get patches without requiring deploying snapshots manually:
In order to do an experimental release for Java 11, all the following steps must be performed:
- Develop the Java 11 code in a feature branch (e.g. "java11-support") so that it does not impact main release line
- Add an "alpha" or "beta" marker to the version of your experimental plugin
- Update to plugin-pom:3.29+ so your plugin embeds the new minimum version of Java requirement in its manifest
- Set the plugin.minimumJavaVersion property in your pom.xml to 11 (see https://github.com/jenkinsci/plugin-pom/blob/master/CHANGELOG.md#329)
- Release your plugin using -alpha-N or beta-N suffices so they are not visible by public instances out there (see the previous point about required and critical improvement only landed starting with Jenkins 2.155).
Long term solution
The If if you forget about any of the bullets above, the update may impact Java 8 users. The long-term solution is already on its way, but is not delivered yet. It's partly delivered by you bumping to the last 3.29+ parent pom so your plugin embeds a "minimum Java" metadata, plus adapting Jenkins core to use this metadata to filter out releases for a version of Java that is higher than the current runtime. Follow