-
Notifications
You must be signed in to change notification settings - Fork 133
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
[24] Top Level Bug for Java 24 Support for JDT.Core #2899
Comments
Quoting @mpalat from #2985 (reply in thread):
plus:
So, we are past M1, so let's check:
|
I created #3228 for this |
Last time, we spoke about having these scripts in JDT. I am still wondering if we should do that or keep it the current way. |
Can you provide a pointer to the scripts used so far, so we can get a clearer picture?
If all fails, we could even try to script this on our own: pulling artifacts from a Y-Build and only perform these additional steps:
All might perhaps be solved with just a few shell commands? |
These are the ones: https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/tree/master/cje-production/P-build
My first thought was we could put them in https://github.com/eclipse-jdt/eclipse.jdt. I don't know if the repo really has to aggregate all the bundles to be built. Honestly, I am not sure one way or other. |
Thanks this helps! At the core I see one mvn invocation in mb220_buildSdkPatch.sh which uses this pom. So far nothing fancy (except for the large number of build properties).
java23patch/pom.xml expects all these mvn modules to be accessible in the filesystem:
The releng build uses git submodules to pull all those into the aggregator git. I don't think we'd want to start anything like that. Perhaps the approach of least effort is: to essentially use those scripts indeed, but rather then relying on git submodules, use a shell script to manually clone (or export) individual jdt repos into folders of the jenkins workspace. I'm just not yet convinced that a full blown build is even necessary, given that we could pull artifacts from a Y-Build, and only add the feature plus metadata. I might give both strategies a try - time permitting :)
|
@stephan-herrmann Full build is not needed according to me too and @merks even proved the P-build could be done far simpler in eclipse-platform/eclipse.platform.releng.aggregator#2341 (comment) |
Thanks for the reminder, but I think this is not much different from cje-production/P-build/mb220_buildSdkPatch.sh and assumes to be run in the aggregator context with git submodules, no? (See that several jdt plugins from different git repos are built as part of one maven build). Our purpose here, however, is to become independent of that aggregator context, as to unburden platform releng :) |
Yes @jarthana and also https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/JenkinsJobs/YBuilds/P_build.groovy ,Jenkins Job |
Thanks, @MohananRahul , so there is some more complexity :) With all that input, let's please continue in #3244, thanks. |
Monitoring of test results in ep434Y-unit-cen64-gtk3-java24 looks promising Plus one failure in releng (regarding comparator logs, which I believe we can ignore for the time being). |
I updated the list yesterday night and at this point - this list may not have too many changes now, I believe. |
Umbrella bug for Java 24 activities - Ref :
https://openjdk.org/projects/jdk/24/
https://openjdk.org/projects/jdk/24/spec/
[for reference to previous release -> Java 23 support captured in issue #2212 ]
for updates on 24
Features for Java 24 release (may change):
Batch Compiler:
JSR 399 Issue
The following issues may warrant issues of their own - Will be created if required
IDE Support for the relevant features listed above under Batch Compiler
Additional Tracking Issues
JDT Core Friends' reference
The text was updated successfully, but these errors were encountered: