Fix #39 - Slicer should allow filtering of a requirement based on the IU currently processed

[laeubi]

No description provided.

[mickaelistria]

How is this supposed to be used? A custom implementation of Slicer that does override those methods should be provided?

[laeubi]

A custom implementation of Slicer that does override those methods should be provided?

I think the most usual case is to extend the slicer, e.g PermissiveSlicer, or Tycho extend this class. The problem is that one can't get a back-pointer to the IU from a requirement so passing both is needed if one want to decide based on IU if a requirement is valid or not.

[laeubi]

okay I might misunderstood that comment, there is only one extension in P2 of Slicer and I'd like to possible change/enhance this on a later change.

[laeubi]

These are the relevant Typcho issues:

• Use PermissiveSlicer directly in tycho-build to compute project dependencies eclipse-tycho/tycho#838
• Not all (direct) requirements of a feature are considered when building an update-site eclipse-tycho/tycho#898

if there are no major concerns I'd like to ask that this is being merged , as this is an internal class we do not introduce new API and its quite obvious to provide the implementation with as much context as needed.

[akurtakov]

I don't see any issue with this one. @mickaelistria is the one with deepest knowledge in the area but he would not be able to look into it in the next couple of weeks. Thus I think it's fine to merge.

[laeubi]

Alright, would a committer be so kind to merge this then :-)

[HannesWell]

Alright, would a committer be so kind to merge this then :-)

Done. :)
I agree with the estimation of both of you. Although I'm not very familiar with that part it looks like we don't damage much and I trust you that there is a good need for it.