update to orbit 2024-12

[cdietrich]

No description provided.

[github-actions]

Test Results

  6 460 files  ±0    6 460 suites  ±0   3h 15m 13s ⏱️ - 7m 56s
 43 242 tests ±0   42 658 ✅ ±0    584 💤 ±0   0 ❌ ±0 
170 113 runs  +4  167 740 ✅ ±0  2 358 💤 ±0  15 ❌ +4 

Results for commit ed99074. ± Comparison against base commit 643087f.

[LorenzoBettini]

You forgot to increment the sequenceNumber but that's fine.

For the future, I think it is crucial to update the sequenceNumber at least in the latest target file, to be sure that Oomph or locally the target platform gets updated when pulling from Git repository.

[cdietrich]

@LorenzoBettini i gave up on this. oomph forgets my tp each day anyway

[LorenzoBettini]

@LorenzoBettini i gave up on this. oomph forgets my tp each day anyway

What do you mean by "forget"?
However, I was talking more about the situation where one pulls from Git, not necessarily Oomph.
When you pull from Git and the sequence number of the current TP is increased, PDE should realize that it has to update the TP. Or maybe I'm wrong, cc @HannesWell.

[cdietrich]

basically everytimei come back to the xtext dev env there is a ton of errors due target platform and i have to reoomph

[LorenzoBettini]

If the errors are due to the tp, I'd suggest you simply open the .target file, let it resolve, and then choose Reload. Of course, this will trigger a rebuild.

Unless, you want to update the IDE, the above operation is faster than re-oomph. At least, in my experience.

[cdietrich]

yes i do execute the "execute setup" all the time. and this is tedious. but i have no idea what causes it

[HannesWell]

However, I was talking more about the situation where one pulls from Git, not necessarily Oomph.
When you pull from Git and the sequence number of the current TP is increased, PDE should realize that it has to update the TP. Or maybe I'm wrong, cc @HannesWell.

You are absolutely right. There are many things in the Target Editor respectively the TP handling that should be improved in PDE. It's on my list, but I haven't had the time yet to do it.

If I understand your case correctly one workaround is to first open the target file using the default target editor, wait until it is resolved and then run the Oomph setup.
It's not good that this is necessary, but at least it was a working workaround in my cases, e.g. the Eclipse SDK target is updated and I subsequently run the Oomph setup that includes it.