Filter bundles with preference for the target state

[laeubi]

Currently it can happen that one bundle (in this particular case org.eclipse.pde.junit.runtime) is not part of the target platform and therefore selected from the running host. This then pull in even more from the host through the DependencyManager collection leading to duplicates all over the place.

As long as target and host are equal enough it does not cause any problem as id+version are the same and so are canceled out but if not this leads to multiple version unnecessary included and this is especially a problem for singletons.

This now:

• collects all items as before
• put everything into a new state and performs a resolve operation
• during the resolve make sure we filter out providers whenever there is an alternative from the target platform.

Contributes to #2082

There is just one issue I'm currently investigate that the determination of the EE currently is faulty if one creates a new runconfiguration from scratch. If one edits the run config one more time (e.g. open it and then run) it works because then the right EE is set and found. Fixed that... the general problem remains and is reported here.

[github-actions]

Test Results

   771 files     771 suites   53m 13s ⏱️
 3 633 tests  3 577 ✅  54 💤 2 ❌
10 833 runs  10 668 ✅ 163 💤 2 ❌

For more details on these failures, see this check.

Results for commit bf752a8.

♻️ This comment has been updated with latest results.

[akurtakov]

With this PR org.eclipse.osgi problem is fixed but 4 others (in this case ) stay:

[laeubi]

I don'T see the problems with your provided example so "something" seems to be broken in your config, I would recommend to completely delete the runconfig and create one fresh, make sure to only select the testbundle itself

[akurtakov]

Same result after deleting the launch config and created a new one via "Run As/JUnit Plug-in Test"

[akurtakov]

The good news is that it let's the test run with a whole of log in the beginning about resolving state.

[laeubi]

The good news is that it let's the test run with a whole of log in the beginning about resolving state.

It might be that just the validation dialog is broken but with the example here (test.me.zip) and latest SDK I get no error, so I would need another example to see the problem you reported.

[akurtakov]

Change to run with product e.g.

If one imports test.zip PDE decides it should generate launch config this way. When I import your project it decides to use "No application" . It's beyond me what it bases this differente on.

[laeubi]

It's beyond me what it bases this differente on.

No problem... I'll merge these and then look what is the difference here...

[HannesWell]

Since we actually try to reduce and eventually get rid of the ancient org.eclipse.osgi.service.resolver API, I wonder if this couldn't be solved simpler. For example by computing the dependency closure immediately only of the junit-requirements (be they from the host or the target) and then by checking if a compatible version (i.e. with the same major segment) is already in the launch or at least in the target (if the bundles are from the host).
This way we should get the same effect but without using a significant part of the org.eclipse.osgi.service.resolver API.

Due to the additional engine requirement of the jupiter-api bundle, which is satisfied by the jupiter-engine bundle, at least the junt-bundles should always be in the TP as otherwise they would be missing for compilation.
So the bundles that may be looked up in the host are the jdt/pde.junit.runtime bundles and their non-junit requirements.

In general I would have appreciated, if more time would have been given to other reviewers to bring up for example this suggestion before this is submitted.

[laeubi]

Since we actually try to reduce and eventually get rid of the ancient org.eclipse.osgi.service.resolver API, I wonder if this couldn't be solved simpler.

I tried to use the new Resolver API but it does not worked out well so I fear even though the "old" is discouraged the new one is not really an alternative as it lacks some features we use in PDE.

For example by computing the dependency closure immediately only of the junit-requirements (be they from the host or the target) and then by checking if a compatible version (i.e. with the same major segment) is already in the launch or at least in the target (if the bundles are from the host).

This code actually do it, but without assuming what could possibly be "compatible", also we can't check the launch because it does effectively contains nothing at that point (except the test bundle itself)

In general I would have appreciated, if more time would have been given to other reviewers to bring up for example this suggestion before this is submitted.

We can always change it and I have already considers some alternatives, the original change was weeks in the pipeline and seems still flawed as reported by @akurtakov so we need to at least make some progress as we are approaching M3 in a few weeks.

If one would aim for something "simpler" (while I think the problem in general is not simple to solve) we would need to modify the DependencyManager considerably what I like to avoid in this late stage and in the past was a guarantee for a PR to be stalled because of concerns because it is used elsewhere.

So current solution is:

1. fast (we only have a very small subset of bundles that we know should resolve)
2. correct (we use OSGi itself so no need to depend on names of bundles or assume things, e.g. especially Junit has some incompatible things in their change of package imports that are not trivial to get right manually)
3. does not require any assumptions about the nature of dependencies, if you debug it you will see that it will pull in a whole lot of duplicates here (including the OSGi framework itself) so I really don't think we can (or should) fix it manually in a "simple" way.