Hi Serge and Martin, You both raise interesting points! I think you're right and agree exclusions are complementary to links.
A couple quick points. I noticed over the weekend that on the "Resource Exclusion Filters" bug (https://bugs.eclipse.org/bugs/show_bug.cgi?id=84988) JohnA states in comment 16 that exclusion filters are supported in the current platform -- albeit in a roundabout way: " You can create an exclusion filter in I20060110 by creating a linked resource to the "null" file system. The linked resource will hide any file system resource with the same name, thus acting as an exclusion mechanism." Now I find this really interesting because I think the two features -- enhancing linked resources & groups, and these exclusion filters -- are two sides of the same linked resources / alias management coin. Given that these exclusions are implemented on top of linked resources, if bugs / performance are fixed / improved in one, the other benefits for free! I see problems with using the existing linked resources implementation: Sharing: As Martin said team sharing a large .project file will become more of a problem. I have a project with 85 linked resources which is 17k of text. It's certainly very important that a team can share a project built like this especially for large projects coming from flexible VS style projects. Performance: Serge if I use your linked resources feature to it's full and create a completely virtual project entirely of groups and linked files, the .project file might be full of thousands of items. A simple optimisation might be to say: Include this tree <some_tree_location_root>, virtually. Exclude: these subtrees and resources: x, y, x resources matching this filter: *.jpg The virtual flag would tell Eclipse to build the tree from the given filesystem location as 'linked resources' and 'groups'. Deleting files or groups would result in an additional 'exclusion' (or deletion of the actual resources if the user chose to do so). >>> 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? Yes, that's right. So you could imagine a Navigator style view which shows the complete tree of EFS resources provided (they're not real Eclipse IResources - no metadata, no delta notification). From this view the user can choose to create / import projects, as well as trees of resources into existing projects. When a resource is added to the workspace it becomes managed by Eclipse. So effectively a Windows Explorer that speaks EFS. Cheers, James _______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
