All statisfied requirements map to dependencies in InstallableUnitSlicer.computeDirectDependencies

[merks]

There are two cases where a requirement should not map to a dependency.

1. When Requirement.getMax() == 0, i.e., for so-called negative requirements.
2. When IRequirement.getFilter() != null and the filter is no applicable.

Mapping those two cases inappropriately can and does result in dependency cycles that break a build (for builds that worked for Tycho 2.x and 3.x).

Currently org.eclipse.tycho.p2maven.InstallableUnitSlicer.computeDirectDependencies(Collection<IInstallableUnit>, IQueryable<IInstallableUnit>) does not have enough context to determine if a filter is applicable or not, so the best we can do in the absence of such information is to assume the filter isn't applicable.

[laeubi]

@merks can you explain what context are needed? ws/os and maybe system properties?

[laeubi]

@merks I now have analyzed the problem and it is actually a bit more complex as initially thought:

1. first you are right that negative requirements are handled as regular ones, but the more general problem is that Tycho does not consider the req.getMax() at all, this is quite easy to fix and I'll provide a PR for that.
2. You are also right that filters are not considered, I have a solution to evaluate them but this can't be applied at the moment because it revealed another problem here see below.
3. The root cause of all evil (beside the rather trivial problem 1.) is that currently we compute the project dependencies for each project and then hold them in a map. Based on that we now compute the inter-dependencies and projects to consider as an additional requirement. Now the following can (and does happen, e.g. for SWT build):

There is a project (look for example at p2Inf.hostRequireFragment, where there is a host a fragment and the host requires the fragment with a p2.inf but disable the filter with a property.

The consumer requires the host and therefore should require the fragment, and do not disable this by a property.

Because we compute the dependencies only once for a project, it is not included! Instead one needs to recompute the dependencies to be used based on the profile properties of the requesting project!

[laeubi]

While your testcase will be good to verify case (1) I think one needs a similar construct like this:

• Ensure that the mac os parts are installed together eclipse-jdt/eclipse.jdt.debug#211

to reproduce case (2) fully, where there is a bundle that wants to require another bundle (not fragment!) with p2.inf but only for one platform on a multi-platform build. Such a testcase can be quite tricky to build i fear.

[merks]

You're awesome. 🎖️