-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Use JabRef's JDK21 build #10004
Use JabRef's JDK21 build #10004
Conversation
@@ -47,6 +47,10 @@ java { | |||
// Workaround needed for Eclipse, probably because of https://github.com/gradle/gradle/issues/16922 | |||
// Should be removed as soon as Gradle 7.0.1 is released ( https://github.com/gradle/gradle/issues/16922#issuecomment-828217060 ) | |||
modularity.inferModulePath.set(false) | |||
|
|||
toolchain { | |||
languageVersion = JavaLanguageVersion.of(20) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That needs to be 21
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought,, 20 is the latest release version (21 is in ramp down, isn't it? - https://openjdk.org/projects/jdk/21/). That version is used generally (tests, ...). Exception; When using jlink, 21 is used. I thought, it is a good idea.to modify one workflow only instead of changing all (JDK custom build download etc)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I change this with sed in deployment.yml
Can't we just use the GitHub artifacts that are build and upload them to our server? Think this pr is a bit too early |
Artifacts are cleared after 30days. Should we build the JDK each month?
I assume the patch will take two or three JDK releases until it is included. Don't want to wait such a long time. I also see this PR as unblocker for a release using java-keyring to store passwords "properly". |
I mean building the jdk once using CI (like they do), then uploading the artifact to our server Seems to be easier to copy the existing workflow |
The build is even created automatically. Example: https://github.com/JabRef/jdk/actions/runs/5239968107/jobs/9460305999 Windows fails at |
The artifacts will be available after the complete run. See actions/upload-artifact#181 for more information. |
Yes, we just need to get this jtreg download fixed |
They also happen at the main repository (https://github.com/JabRef/jdk/actions/runs/5239968107/jobs/9460306443). Thus, I hope, someone of the OpenJDK team picks up. |
at |
Build available at https://builds.jabref.org/pull/10004/merge/ The about dialog is of strange size here (Windows). Does anyone else also experience issues here? |
We need to move forward because of JabRef release blocking issues. In case something breaks, we will need to investigate then. |
We will also probably add notarizations and singing for the mac jdk version
as well
Oliver Kopp ***@***.***> schrieb am Do., 29. Juni 2023, 04:57:
… Merged #10004 <#10004> into main.
—
Reply to this email directly, view it on GitHub
<#10004 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACOFZFVRDZPLSM3WOGWDDTXNSEDPANCNFSM6AAAAAAZCTFTHE>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
I put #10041 to the v5.10 milestone. |
jdk 21 mac path is probably: signing overall of the jdk https://github.com/openjdk/jdk/blob/master/doc/building.md#macos-1 |
Background:
Idea:
Binaries:
Ancient stories:
Before jpackage, we used install4j - see #5312 for details.
Mandatory checks
CHANGELOG.md
described in a way that is understandable for the average user (if applicable)