[Setup] Reference xtext target-files in Xtext's Oomph Setup directly

[HannesWell]

As suggested in #2207 this PR aims to simplify Xtext's Oomph setup by using the xtext-target files used in the Tycho/Maven build also in the Target-Platform of the development workspace.

This avoids the need to replicate and maintain all different target platforms as pure Oomph Targlets.
Use one TargletTask for each xtext-target file (the targlet-task contains the target-file as 'composedTarget') and use a corresponding filter to activate that task if the 'eclipse.target.platform' variable has a corresponding value.

Only for the o.e.cbi.p2repo.analyzers dependencies a always active TargletTask with corresponding Targlet is created, because they are not contained in the target-definition specified by the target-files. That targlet is merged with the one activated for the selected Eclipse target. Without the p2repo-analyzers dependencies or if they where contained in the target-files Xtext could use a simple TargetPlatformTask (if it is not desired to merge the TP with the Targlets defined by other Projects in the workspace).

I checked for all supported TPs that the right target-file is selected and tested the workspace with the latest (aka 2023-06), the 2023-03 and oldest 2022-03 target and all of them resulted in an error free workspace.

[cdietrich]

need to try this out

[cdietrich]

am getting

        ERROR: org.eclipse.equinox.p2.engine code=0 session context was:(profile=TARGET_DEFINITION:resource:/xtext-parent/xtext-latest.target, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=).
        ERROR: org.eclipse.equinox.p2.artifact.repository code=0 No repository found containing: osgi.bundle,de.itemis.xtext.antlr,2.1.1.v201405091103
        ERROR: org.eclipse.equinox.p2.artifact.repository code=0 No repository found containing: org.eclipse.update.feature,de.itemis.xtext.antlr.feature,2.1.1.v201405091103
        ERROR: org.eclipse.equinox.p2.artifact.repository code=0 No repository found containing: osgi.bundle,org.antlr.generator,3.2.0.v201405091103

for latest.
this is an optional dep that should not be resolved

of course(tm) the 2nd try no issue. will have to test on other machine too

[cdietrich]

for some reason we had the itemis update site in the targlet before
@szarnekow @kthoms do you know/remember why?
comfort?

[HannesWell]

for latest.
this is an optional dep that should not be resolved

For me it worked well, but I have only tested it in my existing xtext workspace. Will try it again in a clean one.

for some reason we had the itemis update site in the targlet before

To me it also looked like there were some inconsistencies between the target files and the workspace TP defined by the Oomph targlets. But because the target-files are used in the CI I assumed they should work and did not made a detailed comparison.

[LorenzoBettini]

for some reason we had the itemis update site in the targlet before @szarnekow @kthoms do you know/remember why? comfort?

I've always thought that's because of the antlr generator so that it's not get downloaded if we run mwe2 workflows.

[szarnekow]

because of the antlr generator so that it's not get downloaded if we run mwe2 workflows.

Yes, exactly. It's for convenience and dev experience.

[cdietrich]

maybe we can add it to the cbi section or create a sibling to it?

[HannesWell]

maybe we can add it to the cbi section or create a sibling to it?

Definitively. I'll update this PR.

[HannesWell]

Can you tell me which IUs to install from the items update-site?
Looking into the repo I find the following ones, but AFAICT no one of them was previously in the workspace TP/Targlet created by the Oomph setup:

[cdietrich]

de.itemis.xtext.antlr it requires the 2nd plugin

[HannesWell]

de.itemis.xtext.antlr it requires the 2nd plugin

Thanks. Added the de.itemis.xtext.antlr.feature.feature.group, since if installed with a feature the experience in the Installation details is usually better.

[LorenzoBettini]

I'm not sure I understand the last change (that's why I don't like push-forces in PRs ;) ;)

isn't the de.itemis.xtext.antlr.feature.feature.group already in our target platforms?
Why does it need a special treatment Oomph setup?

[cdietrich]

@LorenzoBettini no its not. and it also should not.
but it was in old oomph

(we dont generate workflows in build)

[LorenzoBettini]

@LorenzoBettini no its not. and it also should not. but it was in old oomph

(we dont generate workflows in build)

But it is in the target platform: https://github.com/eclipse/xtext/blob/main/xtext-latest.target#L42

[cdietrich]

hmm this is also new to me.
so dont care. adding the requirement would be fine then.

[LorenzoBettini]

hmm this is also new to me. so dont care. adding the requirement would be fine then.

I don't understand what you mean: if it's in the target platform file it's useless to add it in Oomph, or am I missing something?

However, I tested this PR locally and it works for me! :)

One small note we should be aware of: by using .target files we rely on PDE, and this means that we'll have the

.metadata/.plugins/org.eclipse.pde.core/.bundle_pool/

in the workspace, containing features and bundles, while with standard Oomph targlets that directory was not populated and the Oomph bundle pool was completely reused.

I'm fine with that. Even though some disk space is used, I prefer to have only single target files to maintain.

[LorenzoBettini]

As usual, I'm stopping the CI jobs since they're useless for this PR.

[LorenzoBettini]

let's hear from @szarnekow

[HannesWell]

I'm not sure I understand the last change (that's why I don't like push-forces in PRs ;) ;)

If you click Compare next to the force-push notification then you can see the diff between the two commits.

After a rebase this also includes the changes from the commit one rebased on, but in case different files are affect you can see quite quickly the change within the PR.
In general I understand that concern and agree that it is not ideal, but in my opnionen git histories with (many) merge commits are also hard to understand. And assuming that the history is read more often afterwards than during PR review I find the choice of not using merges better.

If you want to make it easier to compare one could simply first rebase and force-push and the do additional changes or the other way round. This way you get two compares.

@LorenzoBettini no its not. and it also should not. but it was in old oomph
(we dont generate workflows in build)

But it is in the target platform: https://github.com/eclipse/xtext/blob/main/xtext-latest.target#L42

That's right and as far as I can tell not even one itemis plugin or feature was in the Oomph-Setup TP.
Looking at the git blame Christian added it to the older target-files in 554c1c7.

Any way, since it is now in the Oomph-setup created TP of the workspace, should it then be removed from the TP (in a subsequent PR)?

[HannesWell]

One small note we should be aware of: by using .target files we rely on PDE, and this means that we'll have the

.metadata/.plugins/org.eclipse.pde.core/.bundle_pool/

in the workspace, containing features and bundles, while with standard Oomph targlets that directory was not populated and the Oomph bundle pool was completely reused.

That's right. And that's something I wanted to change in PDE for a while, so that the shared bundle pool for the InstallableUnit target location too, but didn't have the time to look into it and nobody else did too.

[LorenzoBettini]

@HannesWell thanks for updating this PR.
From what I see, the "Working Sets" part is kept intact, so I'm still fine with the PR.
If @szarnekow agrees, we can merge it.

[HannesWell]

One small note we should be aware of: by using .target files we rely on PDE, and this means that we'll have the

.metadata/.plugins/org.eclipse.pde.core/.bundle_pool/

in the workspace, containing features and bundles, while with standard Oomph targlets that directory was not populated and the Oomph bundle pool was completely reused.

Just created eclipse-pde/eclipse.pde#577 to track any future effort in the area.