[Build] Update to Tycho 5.0.2

[HannesWell]

Part of

• Update to tycho 50 #3509

[github-actions]

Test Results

  4 854 files   -  1 607    4 854 suites   - 1 607   2h 24m 10s ⏱️ - 39m 36s
 43 240 tests  -      2   42 656 ✅ +     3    584 💤 ±  0  0 ❌ ±0 
127 643 runs   - 42 412  125 890 ✅  - 41 823  1 753 💤  - 581  0 ❌ ±0 

Results for commit 4345242. ± Comparison against base commit 479dbc8.

This pull request removes 2 tests.

org.eclipse.xtend.ide.tests.editor.XbaseEditorOpenClassFileTest ‑ Unknown test
org.eclipse.xtend.ide.tests.editor.XtendEditorChangingClasspathTest ‑ Unknown test

♻️ This comment has been updated with latest results.

[cdietrich]

With respect to the wizard and tycho needing 21 to run this is why we in the past also ditched old Java version support
Am not sure
if people who will select Java 17 in the wizard know how to setup tool chains or that they have to when they see the error message

but I currently have no time nor mental capacity to address the big update everything task nor seems to have someone else

[HannesWell]

With respect to the wizard and tycho needing 21 to run this is why we in the past also ditched old Java version support

Yes, but since we are late in the release cycle and it was mentioned in #3546 (comment), that Java-17 support is intended until the next release cycle I didn't want to do that for now.
My primary goal is to have Runtime support for Java-25 in the IDE and the xtend-maven-plugin as soon as possible, ideally in the upcoming release.

And you said that Tycho 5.0 would be a prerequisite.

I'm happy to help also with the big tasks in the next cycle, but for now I assume that's out of scope?

Am not sure if people who will select Java 17 in the wizard know how to setup tool chains or that they have to when they see the error message

Yes, I'm currently investigating if the use of a corresponding maven-enforcer rule could at least clarify the situation and make the build fail with a meaningful message in case Java<21 is used to run the build.

[cdietrich]

yes, from my pov all should go into next release.
i dont even really have time to build m3 this week and release next week

[HannesWell]

yes, from my pov all should go into next release.

Do you think there is any chance to have at least minimal runtime support for Java-25 in the upcoming release?
E.g. the corresponding compiler constants available so that the xtend-maven-plugin doesn't fail when running with java-25?
I can try to create such a minimal PR.

[cdietrich]

i fear that would lead to utterly chaos in wizard etc.
i also have no time to support in any capacity

what happens if user selects java 25 here

in any of the combinations

[cdietrich]

and ofc we inherit a lot of our runtime behaviour from old jdt here
https://github.com/eclipse-xtext/xtext/blob/main/org.eclipse.xtext.dev-bom/pom.xml
and new jdt might explode code needs 21 as minimum runtime

[cdietrich]

=> how would it help to just edit

the ClassFIleConstants copy (if we still have that somewhere where i cannot find it right now)

[HannesWell]

i fear that would lead to utterly chaos in wizard etc.
i also have no time to support in any capacity

Too bad, but I understand. Lets discuss if we can achieve something minimal for Java-25 in

• Add compiler support for Java-25 and set up a Java-25 build #3604

[HannesWell]

Am not sure if people who will select Java 17 in the wizard know how to setup tool chains or that they have to when they see the error message

Yes, I'm currently investigating if the use of a corresponding maven-enforcer rule could at least clarify the situation and make the build fail with a meaningful message in case Java<21 is used to run the build.

Using enforcer does not really help, because Tycho must be configuration as an extension and e.g. Tycho's custom packaging-type classes are loaded very early when a Maven build is bootstrapped. And the enforcer rules aren't checked that early. So the build fails with an errors that tells (relatively far down in the stack) that the class file version is not supported by the runtime.
One can understand that, but it's a bit more advanced.

[cdietrich]

@HannesWell can you check what of this is missing on #3638

[HannesWell]

This now also includes your change from

• Update to Java 25, Newer tps, etc #3638 (comment)
  and
• 284464b

I had the impression that especially the latter fixed the remaining failure that was encountered here too.
So I hope that this is it for Tycho-5.

[HannesWell]

This now also includes your change from

* [Update to Java 25, Newer tps, etc #3638 (comment)](https://github.com/eclipse-xtext/xtext/pull/3638#issuecomment-4029041748)
  and

* [284464b](https://github.com/eclipse-xtext/xtext/commit/284464bdafe6458c23c9f616c680eba22b43746b)

With that, the build is now a full success in all configurations. 🎉

I'm contemplating to implement my suggestion from #3638 (comment) and configure the generated launch configuration to require a Java version required for Tycho plus to show a info in the Editor if the Tycho java runtime requirement is higher than the targeted java version.

Do you think that should be sufficient to help users to prevent build problems?
Then this change doesn't have the drop Java-17/require Java-21 prerequisite and for the future there is also a strategy if at one day Tycho is again 'ahead'.

Alternatively I can as the Maven folks if there is a better way to fail the build very early and clearly if the runtime java version is too low.
But actually even now the error message indicates the problem, to be frank a bit obfuscated through the class file version, but in times of AI that systems should be able to explain in simpler terms for users.

So from my POV it would be sufficient with the two items from above.
@cdietrich, what do you think?

[cdietrich]

i guess we can sit it out for now and address it later with my pr after all the rebases.
(same for the xtext-reference-projects, am not sure if you saw my pr there)

maybe we can postpone the trickerys you proposed for platform 25 in 2026-09

[HannesWell]

i guess we can sit it out for now and address it later with my pr after all the rebases. (same for the xtext-reference-projects, am not sure if you saw my pr there)

Do you mean sit out that after this is submitted one has to ensure 'manually' that builds run with a later java version until support for Java-17 is dropped and Java-21 required anyways or that this should go in with your big PR?

maybe we can postpone the trickerys you proposed for platform 25 in 2026-09

I have looked into it a bit already and shouldn't be too complicated, but at the same time I don't want to hold this back further and I'm fine to postpone it into a separate PR.
The mechanism could be introduced even before, even if not effective at that time.

In general I wonder if the number of generated launch configurations can be reduced and if the ones created by default by the IDE are sufficient, i.e. for the tests and mwe2 workflows.

[cdietrich]

i fear this will lead to gigantic merge conflicts with my prs
with sitting out i mean:
if a user selects java 17 and they dont run build with 21 we wont care for now.

btw i fear more the maven build than the launch configs

[HannesWell]

i fear this will lead to gigantic merge conflicts with my prs

I just tested it locally and merged your big branch into this and there were only two small conflicts that were easy to resolve.

with sitting out i mean: if a user selects java 17 and they dont run build with 21 we wont care for now.

Understand, that sounds good. And shouldn't be a problem for a short time.

btw i fear more the maven build than the launch configs

The build of Xtext istself? That shouldn't be a problem because GH workflows and the Jenkins pipeline always run at Java-21 already. The latter uses Maven toolchains to ensure compilation against the specified target Java version.

[cdietrich]

no i mean https://github.com/xtext/xtext-reference-projects/blob/cd-big-bump-2/.github/workflows/build.yml

[cdietrich]

@HannesWell from your pov ready to merge?

[HannesWell]

@HannesWell from your pov ready to merge?

Yes. Ready from my side.
Thanks.

[cdietrich]

thx