Jump to: navigation, search

Difference between revisions of "E4/Resources"

< E4
(New page: <h1>Flexible Resource Model</h1> * From Architecture Council/Minutes May 15 2008#Workspace, Resources, Content_Types: ** Project Nesting *** Physically: Allow .project file below anot...)
 
Line 7: Line 7:
 
** Namespace Resolution (multiple projects with same name in a workspace)
 
** Namespace Resolution (multiple projects with same name in a workspace)
 
** Inclusion of Files from Anywhere on the file system
 
** 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
 
** Add/remove project type/nature
 
** Listeners and plug-in Loading
 
** Listeners and plug-in Loading
** Getting rid of Project for RCP (see also [[e4/RCP Future]])
+
** 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

Revision as of 17:11, 19 May 2008

Flexible Resource Model

  • From Architecture Council/Minutes May 15 2008#Workspace, Resources, Content_Types:
    • Project Nesting
      • 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