Physically: Allow .project file below another .project file be separate full-blown projects -- break iterating over outer's children when finding a project
Logically: Have nested project inherit Preferences from outer project
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
