[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipse-incubator-e4-dev] [resources] Resource Folder filters
|
Hi Serge and James,
Groups & Symbolic links essentially treat projects by
explicitly listing their members, rather than implicitly
picking them up from the file system. One important thing
that we have seen with explicitly listed project members
in the past is this:
the .project file becomes a bottleneck for team operations.
Team members who add/remove a file need to edit the .project
file which lists it. Consider large teams and/or multiple
branches with multiple users who want to edit the .project
file at the same time ... they run into merge issues... and
it all gets very problematic.
Being able to implictly pick up project members from the file
system is one of the big strenghts of Eclipse, and allows for
separation of concerns where only the CM System (CVS, SVN, ...)
is responsible for what files are added/removed.
That being said, I fully agree that there are use cases for
both variants - (a) explicit enumeration when the number of
members is small and/or dispersed over multiple locations,
and (b) implicit pickup with filtering when the number of
members is large and/or follows some rules that can be
expressed as a filter.
When I understood Serge right, the extension point would allow
adding new filter types, whereas the dialog would allow
instantiating those filter types with specific parameters,
right? -- For Reference, the JSR 203 DirectoryStream /
DirectoryFilter goes in this direction on the file system
level, allowing to not even bother looking at directory
entries for items filtered away [1]
I find especially the newContentTypeFilter [2] interesting,
which apparently requires that the file system layer already
has some concept of content types -- something we don't have
in EFS just yet. Given that determining a content type may
be pretty hard and might require actually opening the file
in question, I'm not even sure if it is a good idea to have
the concept of content types at this level. But, if the
actual underlying file system already supports content types,
this is of course a very powerful concept.
BTW, in terms of integration with the underlying CM system,
it would be very interesting to have a Resource Filter which
returns only those directory entries that are actually
managed by the CM system. I'm quite sure that this would
solve a large class of filtering problems, having to provide
the information only once (.cvsignore file, for instance).
Of course, the lifecycle would need some consideration (what
happens when adding a new file that's not yet under team
support... is it visible?), But it's worth a thought.
[1]
http://openjdk.java.net/projects/nio/javadoc/java/nio/file/Path.html#new
DirectoryStream(java.nio.file.DirectoryStream.Filter)
[2]
http://openjdk.java.net/projects/nio/javadoc/java/nio/file/DirectoryStre
amFilters.html#newContentTypeFilter(java.lang.String)
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
> -----Original Message-----
> From: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
> [mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Serge Beauchamp
> Sent: Friday, October 17, 2008 6:57 PM
> To: E4 developer list
> Subject: Re: [eclipse-incubator-e4-dev] [resources] Resource
> Folder filters
>
> Hi James,
>
> James Blackburn wrote:
> > Hi Serge,
> >
> > Isn't this just going to be a less flexible bottom-up
> reimplementation
> > of your groups + linked resources work? Do you expect user
> to change
> > filters on the fly, or are they only set via your filters extension
> > point?
> >
> >
>
> My opinion is that the Linked resources, groups, independent
> paths and
> resource filters are complementary mechanism.
>
> Groups and Linked Resources allows the user to setup the project
> structure by explicitly including files, while the resource filters
> allows setting up the project structure by excluding files
> and folders
> from a larger subset.
>
> Both approach should be fully supported, in my opinion, as
> one is more
> practical for some case than the other.
>
> For example, if the user has a directory with 40 .c files,
> and only 20
> should be included, it would be a hassle to attempt to build a filter
> set for those 20 files, while they can be simply drag and dropped as
> linked resources.
>
> While if the user has a directory with 1000 files in many sub
> directories, and only 20 .c files should be included, putting an
> "inherited" filter on the top directory is a convenient way
> to build the
> project structure.
>
> > Given a choice of both, I'd say VS style groups and linked resources
> > seem the way forward. To me it seems better to allow users to
> > fleixibly pull resources in as they see fit, rather than exclude
> > resources at the outset. What happens, for example, if a
> user were to
> > accidentally change the filter to *.* would they lose metadata on
> > existing resources in the workspace?
> >
> > Doug has mentioned CCRC, and maybe that's the right approach for
> > adding resources from EFS filesystems. A user could change to a
> > Filesystem browser perspective -- much like repository exploring --
> > and choose to pull in linked resources / groups into their workspace
> > as they see fit. Filters could then be implemented at the link /
> > group creation stage. The user could enter some set of expressions
> > for files / folders to filter and the creation dialog could
> show them
> > a preview of the tree that will be created in the
> Workspace. What do
> > you think?
> >
> >
> I'm not familiar with CCRC, but I'd be curious to lean more about it,
> can you point to some example?
>
> Is the FileSystem browser perspective similar to having
> Windows Explorer
> in one window and the Eclipse package explorer in another and using
> existing drag and drop operations?
>
> > Cheers,
> >
> > James
> >
> > On Fri, Oct 17, 2008 at 4:51 PM, Serge Beauchamp
> <serge@xxxxxxxxxxxxx> wrote:
> >
> >> Hi all,
> >>
> >> We're working on a "Resource Folder Filter" feature that,
> a little bit like
> >> Visual Studio does, allows to control which files and
> folders are picked up
> >> when a refresh is performed in the workspace on a folder.
> >>
> >> The Resource Folder Filter works very simply by the
> ability to set a list of
> >> filters (which can be extended with a core resource
> extension point) on a
> >> IFolder, whether it is a standard folder or linked
> resource, and the option
> >> to make it "inherited", in which cases it applies to all
> its children
> >> folders.
> >> A filter can be defined to either "include only" or
> "exclude all" files and
> >> folders matching a given criteria
> >>
> >> A default filter is available that allows the user to
> specify an "include
> >> only" filter that match a string pattern, such as "*.c;*.h".
> >>
> >> This feature will allow significant performance and
> scalability improvement
> >> for users having a large file system tree, as as opposed to hidden
> >> resources, filtered files and folders are not created in
> the resource tree,
> >> so don't consume needlessly resources.
> >>
> >> Let me know what you guys think, thanks!
> >>
> >> Serge Beauchamp.
> >> Software Engineer
> >> Freescale Semiconductor
> >> _______________________________________________
> >> eclipse-incubator-e4-dev mailing list
> >> eclipse-incubator-e4-dev@xxxxxxxxxxx
> >> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
> >>
> >>
> > _______________________________________________
> > eclipse-incubator-e4-dev mailing list
> > eclipse-incubator-e4-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
> >
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>
