Filter all resources of nested projects from their parent

[cobexer]

This way resources only show up in the project closest to them (shortest path to parent) The "Open Resource" dialog no longer offers to open the same resources multiple times, "File Search" no longer finds matches in the same file multiple times (in multiple projects) This greatly improves the user experience for Gradle and Maven projects which normally lay out their related projects in a hierarchial way.

Some usecases that relied on the previous behavior may degrade as a result, which usecases these are and if the degradation should be considered a defect is yet to be determined.

Signed-off-by: Christoph Obexer cobexer@gmail.com

[eclipse-releng-bot]

The Jenkins build of this PR has now completed. See details at https://ci.eclipse.org/platform/job/eclipse.platform.resources/job/PR-169/1/

[merks]

Note that the existing filter mechanism can be used for this type of thing. Here we filter out the children of all folders that don't start with .:

This is what the working tree looks like:

This information is stored in the .project file:

So maybe it would be better to have some action to create such filters rather than try to change behavior in a way that is likely to break assumptions of exist code...

In some git clones, I filter out the target folder of each project because if I do a local Tycho build, I typically don't want search to go into that folder...

[cobexer]

This is way too dangerous:

it will make some IFile or IFolders now unaccessible via APIs

Yes, this is the intent of the change.

and many many extensions (eg builders) do assume that the resources are present.

I'm not convinced that builders expect to work on resources of other Eclipse projects, thats why I submitted this code now so more people can try it out and think about it to find a way get this into eclipse properly.

Many consumers do not care about nested folders and won't recurse to "contained projects".

Is that a good thing, or a problem? Do consumers who don't care about nested folders use them? Or do they avoid them and are thus not relevant for the issue at hand?

Resource filtering is not something that usually works well

If it doesn't work well, then it should be fixed.

and cannot be turned on by default in the API safely.

Maybe it should be possibly to turn it on for Projects? Like Gradle created projects or Maven created projects?

So this change is most likely breaking a long established assumption in a way that's very hard to recover. Maybe this could be an opt-in preferences to try for some time before we make it default?

Yes, I didn't have enough time to make it configurable yet - and did not spend time figuring out where it should be configurable (Product, Workspace, Project,...)

[cobexer]

Note that the existing filter mechanism can be used for this type of thing.

Yes I understand that, but manually setting up such filters is very tedious and in our usecase (Gradle Project Import) this can't be automated. Maybe a checkbox there would be a good place to enable this feature?

[mickaelistria]

I'm not convinced that builders expect to work on resources of other Eclipse projects,

That you never know. The general rule with a 20+ years old piece of software that has been extensible for a long time is that you always find 1 case over the thousands that were implemented that relies on something you cannot even imagine, and that is actually guaranteed by some API contract. That's what make changing defaults always dangerous. I can easily imagine at least 1 builder that does watch or require resource of subprojects: the webtools one. Imagine you have a Java Web Project, and this web project has a builder that takes care of assembling the project into a war (I believe it uses IResource for that); and -for some reason- user wants one sub-part of the project to appear as a nested project because it has some extra nature or whatever; then this builder would suddenly fail at properly building the war because the nested resources are not visibile any more.

Is that a good thing, or a problem?

I don't know really. But it's the state of thing and it makes that this change would break some consumers hardly.

If it doesn't work well, then it should be fixed.

Filtering does what it says it does very well; but as mentioned above, it's not something that most consumers properly deal with. Filtered resources are usually fully ignored, just like if they weren't existing; they also mandate some particular strategy to import stuff or content is fully invisible. But some children resource do matter for the parent project even when nested into a child project and this API proposal doesn't make any difference (because it cannot). Another "design" aspect is for example the search in enclosing projects or selected resources: if I run a search on a parent project, then I expect to see also matches from children folders as well (be them regular folders or nested projects). Your proposal would probably break that and miss matches in nested projects. So it's all working as expected, but the overall design has been there for a long time so that many many consumers to rely on this behavior -for better or worse- and that makes it a dangerous area.

Yet, I really believe this proposal is interesting, it's just too early to make it the default IMO. As for a configuration flag, let's not go into too fine grained work: a configuration flag for the whole workspace should be a good 1st iteration. Then once we have it, we'll see whether we want something finer or not.

About the manual resource filters, 1 issue is that they are too static IMO: if I import just the parent project in my workspace and this parent has resource filters, I cannot see the children folders so it seems like the project is empty! That's relatively hard to realize that resource filters are the cause and this requires to tweak them back in order to show folders. Your proposal is more dynamic and would prevent from having to perform those modifications.

[merks]

Note that the existing filter mechanism can be used for this type of thing.

Yes I understand that, but manually setting up such filters is very tedious and in our usecase (Gradle Project Import) this can't be automated. Maybe a checkbox there would be a good place to enable this feature?

My sense though is that changing the behavior in such a fundamental way is kind of a non-starter. However, if one were to provide some action that can be performed on all the projects in the workspace to create filters that automatically do what you want that will not require any API changes. The various import project wizards could provide a way to apply that action during import. I.e., just do something to automate the tedious part of authoring the filters....

[laeubi]

@cobexer we moved this repository in https://github.com/eclipse-platform/eclipse.platform if you think your change is still relevant please reopen the PR there!