Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default buildPlugin() and buildPluginWithGradle() to Java 11 #514

Open
NotMyFault opened this issue Nov 4, 2022 · 10 comments
Open

Default buildPlugin() and buildPluginWithGradle() to Java 11 #514

NotMyFault opened this issue Nov 4, 2022 · 10 comments
Assignees

Comments

@NotMyFault
Copy link
Member

Both calls still default to Java 8, when the minimum Java version to compile plugins against modern baselines require Java 11.

It would be nice to have Java 11 available as default, given that's the lowest supported Java version by now.

@lemeurherve
Copy link
Member

I though about that but as @dduportal noted doing so would break all plugins compatible with Java 8 only (AFAIU).

@NotMyFault
Copy link
Member Author

I though about that but as @dduportal noted doing so would break all plugins compatible with Java 8 only (AFAIU).

Those would just need to specify JDK 8 then, no?

@lemeurherve
Copy link
Member

lemeurherve commented Nov 4, 2022

I though about that but as @dduportal noted doing so would break all plugins compatible with Java 8 only (AFAIU).

Those would just need to specify JDK 8 then, no?

Yes, that's all they need, but until they've done it (if ever), their plugin build will be broken.
We can't break an undetermined number of plugins like that (un)fortunately.

@dduportal
Copy link
Contributor

I though about that but as @dduportal noted doing so would break all plugins compatible with Java 8 only (AFAIU).

Those would just need to specify JDK 8 then, no?

Yes, that's all they need, but until they've done it (if ever), their plugin build will be broken. We can't break an undetermined number of plugins like that (un)fortunately.

+1 with what @lemeurherve said. However this task could be associated to a communication to all plugins developers + eventually a batch of PRs to change on plugins and maintainers could then choose to merge or not WDYT?

@NotMyFault worth an email on the dev mailing list to boostrap the subject?

@NotMyFault
Copy link
Member Author

eventually a batch of PRs to change on plugins and maintainers could then choose to merge or not

Yup, I remember we did similar stuff in the past to accomplish infrastructure changes, like switching to the reusable CD workflow.
Although, I'd imagine that not everyone who calls buildPlugin() only is stuck on Java 8 (thanks to major upgrade campaigns like JENKINS-52012, JENKINS-51805 and JENKINS-52284), the vast majority amount of people possible relies on the one-liner out of convenience, rather having a test matrix to run a subset of tasks on different JDKs.

worth an email on the dev mailing list to boostrap the subject?

Yeah, communication is key. Albeit, I doubt there are many active and maintained plugins and components, which require compilation and execution on Java 8 only.
This could also be seen as a chance for plugin authors to support more Java versions.

@lemeurherve
Copy link
Member

Is there an easy way to identify plugins working only with jdk8?

@basil
Copy link
Collaborator

basil commented Nov 4, 2022

We are in the "phase change" portion of the migration now; i.e., the awkward period where both new and old worlds are supported concurrently. At some point we will have to break with the past and drop support for Java 8 as a first-class citizen in the toolchain, including dropping support for Java 8 in things like the Jenkins test harness, acceptance test harness, Maven HPI plugin, plugin parent POM, etc. My preliminary thinking was that we should wait until at least the 2.375.1 LTS, given that the developer documentation recommends that plugins support 1-3 LTS releases. The plugin parent POM currently supports cores all the way back to 2.249, but I think it is worth shorting our typical support cycle in this case. Unfortunately there is no foolproof way to detect if a plugin is compatible with Java 11 or not, but plugins with a parent POM earlier than 4.40 are unlikely to build and test cleanly against newer Jenkins cores on Java 11 without at least minor build changes.

@dduportal
Copy link
Contributor

@jetersen
Copy link
Contributor

jetersen commented Apr 7, 2023

Well, another way would be to do what plugin pom has done which is to pin the JDK based on Jenkins version?

So, if 2.361.1 use JDK 11.
If below assume JDK 8.

@lemeurherve lemeurherve self-assigned this Apr 7, 2023
@jglick
Copy link
Contributor

jglick commented Apr 7, 2023

archetypes and docs tell you to use an explicit Java version in your Jenkinsfile, so beyond improving the library to warn you (or warn you more sternly?) when relying on the default, I think there is nothing to be done here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants