Community
Participate
Working Groups
Build ID: Eclipse SDK 3.6m5 One of the most common use-cases for resource filters is hiding elements such as backup files which are not relevant in general. There should be a global setting for such a filter:: * Preference Page * configurable by product builders through plugin_customization.ini * Reachable from the Project and Folder Properties Dialog through an "Edit Global..." button
Could you elaborate? Where those filters should be stored? In the workspace or per project?
Global filters should be stored in the Workspace. The most common UI that I see for this concept is for instance in Project > Properties > Java Code Style: [X] Enable project specific settings Configure Workspace Settings... Where the workspace settings are the global ones, and when I enable project specific settings, they are initialized from my workspace settings.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
In my opinion this bug is still valid. Having a global source filter is a good thing to have.
Also see https://stackoverflow.com/questions/14290736/set-resource-filters-globally-in-eclipse
(In reply to Lars Vogel from comment #3) The 'target' folder generated by a command line maven build can be pretty annoying in the IDE, e.g. for xcore modeling files that get validated twice. This shows fake errors because types are defined as well in the 'original' source and in the 'target' folder resulting from the maven build. Yes, you can define exclusions, but only per project. This means that you have to duplicate this more or less 'standard' exclusion over and over again. You can configure exclusions globally in Preferences/Validation, but the XCORE modeling tool that is not listed there. Any suggestions ?
(In reply to Philippe Brossel from comment #6) > Any suggestions ? See comment 2 for proposal. Patch is welcomed. https://wiki.eclipse.org/Platform/How_to_Contribute
.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.resources/+/189150
(In reply to Andrey Loskutov from comment #7) > (In reply to Philippe Brossel from comment #6) > > Any suggestions ? > > See comment 2 for proposal. Patch is welcomed. > https://wiki.eclipse.org/Platform/How_to_Contribute I'm currently trying to build
(In reply to Andrey Loskutov from comment #7) > (In reply to Philippe Brossel from comment #6) > > Any suggestions ? > > See comment 2 for proposal. Patch is welcomed. > https://wiki.eclipse.org/Platform/How_to_Contribute I'm currently working on it and will submit a proposal asap.
(In reply to Andrey Loskutov from comment #7) > (In reply to Philippe Brossel from comment #6) > > Any suggestions ? > > See comment 2 for proposal. Patch is welcomed. > https://wiki.eclipse.org/Platform/How_to_Contribute I would appreciate your advice here. I was mainly interested in this bug because it would have allowed me to exclude the 'target' folder from the workspace by setting a global exclusion filter instead of repeating it in each and every project. Applying such a filter would solve my original problems arising after a command line maven build : - a file search in the workspace shows 'fake' results e.g. searching for 'Bundle-RequiredExecutionEnvironment:' will find /META-INF/MANIFEST.MF and /target/MANIFEST.MF - modeling tools like xcore are misled because they compile source files twice /model/myModel.xcore /target/classes/.../myModel.xcore showing errors on the project and injecting the wrong genModel="target/classes/.../myModel.xcore" into plugin.xml I would like to submit a simple patch to solve at least this. Solution 1 : 'Simply' exclude build folders from workspace - option to be set in the workspace preferences (false by default) - exclude root 'target' folder if set See https://git.eclipse.org/r/c/platform/eclipse.platform.resources/+/189150 Btw. I was not able to push changes to eclipse.platform.ui because of Repository ssh://philippebrossel@git.eclipse.org:29418/platform/eclipse.platform.ui prohibited by Gerrit: not permitted: update error: branch refs/heads/master: To push into this reference you need 'Push' rights. User: philippebrossel Contact an administrator to fix the permissions -> Should I better open a separate bug for that ? Solution 2 : Properties per project or global -> I investigated but need further advice. -> Is it worth doing it if solution 1 is acceptable ? - The requested functionality is implemented in classes extending jdt.internal.ui.preferences.PropertyAndPreferencePage - Can ui.internal.ide.dialogs.ResourceFilterPage use this existing code by adding a dependency or has it to be rewritten (best not duplicated !) ? - should a 'simple' option be added on this page to exclude build folders (as in solution 1) Solution 3 : Something 'better' -> some ideas - developers may want to see the build folders in the workspace without the drawbacks mentionned - is there a better way to tell builder participants or search tools not to consider these folders ? - is there a better way to recognize what a build folder is (i.e. not basing decision on its name) ?
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/189219
@Philippe: Have you tried using Project Explorer filters? Here user can set filters that would hide resources from the Project Explorer based on name pattern. Would that work for you or do you really need full resource filters?
(In reply to Mickael Istria from comment #14) > @Philippe: Have you tried using Project Explorer filters? Here user can set > filters that would hide resources from the Project Explorer based on name > pattern. Would that work for you or do you really need full resource filters? I already investigated that by setting a filter on project level 'Exclude all/Folders/Name matches target' that hides the folder from package explorer where I mostly work with (and project explorer too as you said) It works, BUT : 1) you have to define the filter criterion manually for something that is more or less 'classical' and could be covered by a simple toggle. 2) filters are related to a project, and cannot be defined globally, so you have to repeat them in every project. I'm personally most interested in (1), while (2) would be OK if having a global definition. Here my opinion over pros and cons : (1) (+) simple and global (+) does not collide with other filters (+) no need to review filters when using another command line build tool (-) one more option to set in the workspace (+) is a little bit like detecting output folders like '/bin', i.e. could be done with another technique (2)with global definitions per workspace (+) flexible, covers more use cases (+-) a solution for global/project settings already exists in jdt.internal.ui.preferences.PropertyAndPreferencePage and has to be moved into platform (?) => much more work but may be worth doing it (+) could allow for a simple toggle as for (1) either globally or per project I already prepared a solution for (1), but need further advice for (2). Maybe that (1) should better relocated to a new bug because it somewhat highjacks this bug here, or integrated into (2).
What makes you use Package Explorer more while Project Explorer has a more powerful, and extensible Filter mechanism built-in? The filters in Project Explorer can be defined for a name-pattern manually, but also using https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fextension-points%2Forg_eclipse_ui_navigator_navigatorContent.html . I wouldn't really support the idea of adding some complexity in core resource model just to workaround a limitation of Package Explorer that is already resolved by using Project Explorer...
Created attachment 287766 [details] Project explorer filter settings
What I have in mind is https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Freference%2Fref-27.htm Before we accept such a big and risky addition, we really need to know more about why you need such filters. Can you please explain and detail why Project Explorer filtering described in https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Freference%2Fref-27.htm wouldn't work for you?
(In reply to Mickael Istria from comment #16) > What makes you use Package Explorer more while Project Explorer has a more > powerful, and extensible Filter mechanism built-in? I use package explorer since the beginning (of eclipse). Didn't notice the differences. Good to know. One can indeed set a view filter in 'Filters&Customization' / 'Pre-set filters' where there is an option for 'Maven build folder' (!). This does not seem to work since the view still shows the folder 'target'. Am I doing something wrong ? The option 'User filters' works and it hides the folder 'target' from the view. BUT this is not a solution for my initial problem (see comment 12) - search still finds 2 entries - xcore compiles 2 identical files resulting in errors Defining filters in 'Project properties' / 'Resource Filters' (see attachment 287766 [details]) is identical in both explorers and solves my initial problem : - hides the folder 'target' from the workspace (not only the view) - search now finds only 1 source file - xcore now compiles only the right source file BUT it has to be defined on each and every project. That's the reason why I came to this bug here. > The filters in Project Explorer can be defined for a name-pattern manually, > but also using > https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.platform.doc. > isv%2Freference%2Fextension- > points%2Forg_eclipse_ui_navigator_navigatorContent.html . This seems very interesting but also difficult to set up. Would you mind giving me a hand to get it working ? > I wouldn't really support the idea of adding some complexity in core > resource model just to workaround a limitation of Package Explorer that is > already resolved by using Project Explorer... I understand that. No objections if you see a chance to get my initial problem solved ...
As already sais, see comment 2 for the right direction. The "same" UI we have to define project filters should be added to the workspace and of course the underlying framework changes need to be done to apply the settings on startup.
(In reply to Andrey Loskutov from comment #20) > As already sais, see comment 2 for the right direction. > The "same" UI we have to define project filters should be added to the > workspace and of course the underlying framework changes need to be done to > apply the settings on startup. Thanks for your feedback. I will prepare a patch asap. Just to make sure that I have understood : - jdt.internal.ui.preferences.CodeStylePreferencePage is a good example of global/project preferences - jdt.internal.ui.preferences.PropertyAndPreferencePage where it relies on has to be 'moved' into ui.dialogs - all its direct children (15 or so) including jdt.internal.ui.preferences.CodeStylePreferencePage have to be reworked to use the new platform version to avoid code duplication - at least ui.internal.ide.dialogs.ResourceFilterPage should use the new platform version. Are there others out of the 31 direct children to consider ? Some more questions : - are there other implementations around to be considered or is jdt.internal.ui.preferences.PropertyAndPreferencePage the only one using the global/project mechanism ? - we have 3 concurring mechanisms for filtering resources : - project properties : ui.internal.ide.dialogs.ResourceFilterPage => Only 'project properties' will be considered (good for me because it solves my initial problem). Right ? - project explorer view : ui.internal.navigator.filters.CommonFilterSelectionDialog - package explorer view : jdt.internal.ui.filters.CustomFiltersDialog => why are there 2 implementations ? I want to best avoid this situation for this bug here - wouldn't it be nice to allow to select the 'Pre-set filters' contained in the project explorer view (see comment 18) because 'Gradle build folder' and 'Maven build folder' are already there ?
(In reply to Philippe Brossel from comment #21) > Just to make sure that I have understood : > - jdt.internal.ui.preferences.CodeStylePreferencePage is a good example of > global/project preferences Have no IDE at hand right now, no idea. > - jdt.internal.ui.preferences.PropertyAndPreferencePage where it relies on > has to be 'moved' into ui.dialogs No. Nothing from JDT need to be moved to nowhere. Any JDT is *completely* unrelated. We are in the resources/IDE land. > - at least ui.internal.ide.dialogs.ResourceFilterPage should use the new > platform version. Are there others out of the 31 direct > children to consider ? Not sure what do you mean and why do we need to rework lot of code. I haven't looked into the current implementation, but what we need is a similar UI like one in Project properties page for *Resources* filers. > Some more questions : > > - are there other implementations around to be considered or is > jdt.internal.ui.preferences.PropertyAndPreferencePage > the only one using the global/project mechanism ? For sure there are others. > - we have 3 concurring mechanisms for filtering resources : They are not concurring at all. The one you want to touch is on the lowest *IResource* API level, all others are just "decorations" for various viewers on the same model. Once you have *IResource* API level filters, ALL other code will simply not see *anything* that is filtered out. > - project properties : ui.internal.ide.dialogs.ResourceFilterPage > > => Only 'project properties' will be considered (good for me because > it solves my initial problem). Right ? Yes, this sounds like the right one (as said, no IDE right now). > - project explorer view : > ui.internal.navigator.filters.CommonFilterSelectionDialog > > - package explorer view : jdt.internal.ui.filters.CustomFiltersDialog > > => why are there 2 implementations ? I want to best avoid this situation > for this bug here Because of "not invented here" and different teams working on similar features. > - wouldn't it be nice to allow to select the 'Pre-set filters' contained in > the > project explorer view (see comment 18) because > 'Gradle build folder' and 'Maven build folder' are already there ? First do the basic thing, later you can look into the "nice to have". What do you want: 1) Possibility to save/read workspace level *IResource* based filters in core resources bundle. 2) Possibility to define these filters via UI in global Workspace preferences. 3) Link from / to project / workspace level preference page to define filters. 4) Think about what is applied first - workspace of project filters and if or how that should be reflected in the project resource filters preferences page. What you don't want: 1) Change *ANY* existing JDT/PDE code. All changes should be fully transparent for any client except the UI bundle with the new workspace preferences page. 2) Change *ANY* of existing viewers/explorers etc. All changes should be fully transparent to them. They simply won't see filtered resources.
(In reply to Andrey Loskutov from comment #22) ... > What do you want: > > 1) Possibility to save/read workspace level *IResource* based filters in > core resources bundle. > 2) Possibility to define these filters via UI in global Workspace > preferences. > 3) Link from / to project / workspace level preference page to define > filters. > 4) Think about what is applied first - workspace of project filters and if > or how that should be reflected in the project resource filters preferences > page. > > What you don't want: > > 1) Change *ANY* existing JDT/PDE code. All changes should be fully > transparent for any client except the UI bundle with the new workspace > preferences page. > 2) Change *ANY* of existing viewers/explorers etc. All changes should be > fully transparent to them. They simply won't see filtered resources. Understood. I was just wondering why we have so many implementations of the same thing (basically an abstract DialogPage with a selection global/project and a read/write mechanism) in so many different projects. Maybe that we can discuss these topics later when I have got some more insight (hopefully) ...
Any news ? I can't find any related bug on https://github.com/eclipse-platform/eclipse.platform.ui.
