Community
Participate
Working Groups
Build Identifier: I20110613-1736 The filter org.eclipse.ui.navigator.resources.filters.endsWithClass declared in the org.eclipse.ui.navigator.resources plug-in has a filter expression which uses instanceof for IFile - adapt should be used instead. This means that this filter will not work properly for content extensions which use their own model, but adapt to IResource. Instead the evaluation target should be adapted to IFile (what is already being done for the org.eclipse.ui.navigator.resources.filters.startsWithDot filter). Reproducible: Always Steps to Reproduce: The filter org.eclipse.ui.navigator.resources.filters.endsWithClass declared in the org.eclipse.ui.navigator.resources plug-in has a filter expression which uses instanceof for IFile. This means that this filter will not work properly for content extensions which use their own model, but adapt to IResource. Instead the evaluation target should be adapted to IFile (what is already being done for the org.eclipse.ui.navigator.resources.filters.startsWithDot filter).
Actually, this filter should probably be removed. Nothing at the level of org.eclipse.ui.navigator.resources should have any knowledge of .class files. That's something for JDT. I'm not sure whether the existence of the filter would be considered API (and thus can't be removed), or if we can just get rid of it. Dani/Paul, do you have any comment here?
(In reply to comment #1) > Actually, this filter should probably be removed. Nothing at the level of > org.eclipse.ui.navigator.resources should have any knowledge of .class files. > That's something for JDT. Correct and JDT already contributes a filter for the output folder (which normally contains the class files). Having said that, the interesting question to me is what kind of objects Petar wants to filter with the "*.class" filter. If those are not related to the "normal" Java class files residing in the output folder, then removing the filter contribution would probably be bad for his use case.
(In reply to comment #2) > (In reply to comment #1) > > Actually, this filter should probably be removed. Nothing at the level of > > org.eclipse.ui.navigator.resources should have any knowledge of .class files. > > That's something for JDT. > > Correct and JDT already contributes a filter for the output folder (which > normally contains the class files). > > Having said that, the interesting question to me is what kind of objects Petar > wants to filter with the "*.class" filter. If those are not related to the > "normal" Java class files residing in the output folder, then removing the > filter contribution would probably be bad for his use case. We have a resource based model which adapts to IResource. We don't really want to filter anything with the *.class filter - we wanted to have all navigator content extensions in our common navigator view and the "*.class" filter was part of them, but did not work with our model. Removing the filter is a perfectly acceptable solution for us as we've already excluded it from our view. It seemed odd to us that this filter is part of the navigator content extensions and not the JDT extensions, but we thought maybe there is a reason behind that - hence this bug.
I'm going to remove it then.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
