Namespace Resolution (multiple projects with same name in a workspace)

Inclusion of Files from Anywhere on the file system

Full Native Support for Symbolic Links (avoiding problems with cyclic symlinks)

Add/remove project type/nature

Listeners and plug-in Loading

Getting rid of Project for RCP (see also e4/RCP Future) -- is the notion of "Project" a plumbing or User Artifact? Where should builders etc be hung off?

Content Types:

Pattern Matching for content types rather than just file extensions + stream evaluation

Case sensitive patterns for content types

UI for Project-specific content types

Some ideas that came out of the modeling session

Need a model for the resource system

Need extensible so we can add project properties that get persisted with the project

e.g. so we can get rid of maintaining our own .cdtproject file for the CDT

EMF? Are we ready for IResource to be an EMF object?

How is this persisted?

Using DOM/CSS type thing, we can auto generate the project explorer

Support existing API as facade?

Does EFS become simpler? necessary? if model is extensible

Flexible support - Add/excludes recorded in model

Some Possible Requirements (please feel free to add new ones here)

Flexible

include/exclude resources explicitly, optionally with children (do we need more comprehensive filtering schemes?)

keeps the project file small as if you know you want all children of a folder the project file only needs to store the location of the folder you added and not individual links for all the children beneath it)

Virtual content in resource model

Don't scan for resources until they're asked for. Right now the workspace refresh policy of "refresh the entire project when opened" makes things really slow when you are using EFS to a remote share.

Virtual resources

In other words, break the assumption that the resource model maps nearly one-to-one with the underlying filesystem

Multiple projects should be able to reference the same physical file. Projects should be able to overlap.

Nested projects should be possible

non local projects/resources first class citizens

non-physical projects/resources first class citizens

May have many to one relationship between workspace resources and physical resources (e.g. look at how opening plugin.xml also lets you edit manifest.mf in one logical editor)

More flexible content type schemes

e.g. for MVS, which doesn't have file extensions

Portable (projects/workspaces)

between users/machines/locations

no absolute paths embedded in project files

Consumable

grouping of projects

with or without metadata

Need to store data that dictates how to make the project successfully function, but want to omit preferences that amount to user "taste," e.g. need to save build settings, but not what colour the build output is printed with in the console.

Users want toopen a single "workspace file" a la Visual Studio

Team

Team has to work in the context of the new project/resource model or developers will not use it.

Broken even for current scenarios, wants the root of what it checks out to be the project

Minutes From Meeting at e4 Summit

Issues

projects are currently fundamental(you need one) and heavily overloaded

resources == filesystem

need a mapping from model in workbench to what a particular tool (internal/external) needs

no nested projects

need flat projects

dependencies not modeled

aggregation of projects

.project file not extensible currently

can't have multiple workspaces on the go at the same time - need preference scoping for prefs that span workspaces

import/export is a clunky flow

need non-physical files

need non-EFS extensibility

need to make it so things like RSE can be simpler (no more magic, hidden project for cached files)

resources need to be "on demand" and lazily loaded, model must allow you to know what is/is not loaded

want workspace file/Visual Studio "solutions"

EFS and resource structure are not known by external files

want to team things, build things, separate things

working sets not complete

IResource and EFS are both synchronous, need asynchronous

resource hierarchy should be a DAG

URIs are often non-portable as they can embed connection and user authentication info, which means the project can not be portable between users/machines