Bug 100440 - [Dialogs] Add fitering mechanism to FilteredResourcesSelectionDialog
Summary: [Dialogs] Add fitering mechanism to FilteredResourcesSelectionDialog
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: IDE (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Platform UI Triaged CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-06-16 12:59 EDT by Andrew Premdas CLA
Modified: 2019-09-06 16:05 EDT (History)
4 users (show)

See Also:


Attachments
Shows problem with OpenResource (19.67 KB, image/gif)
2005-06-16 13:01 EDT, Andrew Premdas CLA
no flags Details
2nd example of problem (18.87 KB, image/gif)
2005-06-16 13:04 EDT, Andrew Premdas CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Premdas CLA 2005-06-16 12:59:39 EDT
My attempt to re-open this bug, which has bitten me badly several times today.

Basically there are a number of situations where the default fix does not work.
This is because in many project structures "build files" are sometimes outside
of the default build location that Eclipse uses. So eclipse cannot work out for
itself that these files are derived resources.

Really we need to be able to add locations to exclude from Open Resource. It
would be also useful to be able to add file types to stop Open Resource pulling
out class files and subversion files.

I'll try and attach some screen shots to show examples if I can work out how to
submit them to bugzilla
Comment 1 Andrew Premdas CLA 2005-06-16 13:01:30 EDT
Created attachment 23343 [details]
Shows problem with OpenResource

This shows how two versions of a critical file are selected and how the build
one is the default
Comment 2 Andrew Premdas CLA 2005-06-16 13:04:36 EDT
Created attachment 23344 [details]
2nd example of problem

Showing the inclusion of .svn files and .class files.
Comment 3 Andrew Premdas CLA 2005-08-08 09:30:09 EDT
Its been 2 months since I raised this bug and I haven't had any response. As
this is by far the most serious bug I've ever found with eclipse I would like to
at least try and get a response for it.
Comment 4 Michael Van Meekeren CLA 2005-09-07 17:30:44 EDT
We are able to hide java class files that are part of the output folders for
java projects, so this would seem possible, adding Dirk as a cc.
Comment 5 Dirk Baeumer CLA 2005-09-08 04:58:29 EDT
Michael,

Andrew isn't only talking about class files. The problem are also resource files
(for example .properties, ...) which are copied by the builder to the output
folder (in this  case the build folder). The way how JDT ensure that these are
filter is that the builder marks all files copied into the output folder as
derived and the open resource dialog by default filters derived resources. So I
opt to pass this PR to Web Tools. The have to make sure that the files in the
output folder are marked as derived so that we know they aren't important to the
users.
Comment 6 Andrew Premdas CLA 2005-09-08 05:14:01 EDT
First of all thanks for responding :)

I am talking about all sorts of files here, including .properties .xml and
possiblly just about any other extension except perhaps .java. This is why the
ability to tell Open Resource not too look in certain places would be an ideal
solution.

You also have to be aware that these files may get into these locations via
methods outside the IDE (particularly Ant build scripts). So maybe marking the
files with the Builder isn't the way to go.

Finally a good failsave would be to modify the UI of the open resource dialog so
that if a file has multiple selections you have to specifically select one of
the options (there is no default selections). So in my first screenshot you
could not select action-servlet.xml by double clicking on it in the top section.
Instead you would have to go to the bottom section and choose one of the two
entries)
Comment 7 Michael Van Meekeren CLA 2005-09-08 09:55:35 EDT
Adding Michael Elder, is there a WTP person who ownes the builder and can
investigate marking of resources as derived where appropriate?
Comment 8 Michael D. Elder CLA 2005-09-08 12:36:30 EDT

If this is in specific reference to the WTP builder, I would refer you to Chuck
Bridgham. I happen to know that there are plans to change how that builder
works, but it should be a simple enough change at least for now to mark all
resources that are put in a WTP output structure as derived (if they are not
already). 

Andrew -- Can you confirm if you are seeing this problem under WTP?
Comment 9 Andrew Premdas CLA 2005-09-08 12:59:29 EDT
The problem happens with and without WTP. 

Any fix that is dependent on having WTP installed based wouldn't be sufficient
in my opinion, because this problem really bites even when your not using WTP.

Hope this helps :)

Comment 10 Krzysztof Michalski CLA 2007-08-28 08:49:01 EDT
Andrew, Could you check it once again in Eclipse 3.3 ? 

1. Now to filter build file we use derived flag. As i understand it's insufficient and you expect to add filter mechanism similar to this from package explorer.
2. All svn file should be marked as team private resources by svn plug-in similar to cvs solution. All svn res marked as IResource.TEAM_PRIVATE should be hidden. 


Comment 11 Krzysztof Michalski CLA 2007-09-10 09:45:34 EDT
In conclusion, we will provide filtering feature for FilteredResourcesSelectionDialog.
Comment 12 Szymon Brandys CLA 2008-05-30 07:16:33 EDT
Krzysztof left the team some time ago. I'm removing the target milestone. I will reassign it to the right person, when I find out who it is.
Comment 13 Szymon Brandys CLA 2008-05-30 11:28:33 EDT
Reassigning to Susan.
Comment 14 Susan McCourt CLA 2009-07-09 15:57:03 EDT
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
Comment 15 Eclipse Webmaster CLA 2019-09-06 16:05:03 EDT
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.