The Eclipse Core Resources Project design has evolved from being a simple reproduction of directory in the file system to include more and more complex features.
In order to consolidate and expand the existing Core Resources APIs in Ganymede, and to satisfy demanding customers such as CDT users accustomed to standard IDEs such as Visual Studio and CodeWarrior, improvements need to be done for e4.
In this short talk we will expose the proposed Core Resources changes for e4, including:
Core Resources Filters
Project path variables for linked resources
Groups
We will discuss how those improvements will affect both the users and plugin developers, how existing plugin can be tweaked to take advantage of the new features, and make sure no legacy assumptions is left unchallenged.
45. Jim Bowen (jimbowen0306) Steven Fettig (steven n fettig)
Kyle Pearce (keepitsurreal)
(Ioja)
Etienne Cazin
Michal Shabtiali
(Panoramas)
Wednesday, March 25, 2009
46. QUESTIONS/INFO
serge@freescale.com
sergebeauchamp.blogspot.com
Wednesday, March 25, 2009
Notes de l'éditeur
Welcome
- Projects create order out of disordered elements
- Project requirements: Flexibility, ease of use, scalability.
- Very hard to prevent files to be visible under a directory.
- Linked resources made projects non-portable, and were underpowered
- Project structure can’t be fully logical (no groups).
- Very hard to prevent files to be visible under a directory.
- Linked resources made projects non-portable, and were underpowered
- Project structure can’t be fully logical (no groups).
- Very hard to prevent files to be visible under a directory.
- Linked resources made projects non-portable, and were underpowered
- Project structure can’t be fully logical (no groups).
- Virtual folders, can be filters or not
- Automatically sorted by filters
- Relative Paths can be relative to macros such as $(VCInstallDir)
- Not easy to use
- Virtual folders, can be filters or not
- Automatically sorted by filters
- Relative Paths can be relative to macros such as $(VCInstallDir)
- Not easy to use
- Virtual folders, can be filters or not
- Automatically sorted by filters
- Relative Paths can be relative to macros such as $(VCInstallDir)
- Not easy to use
- Virtual folders, can be filters or not
- Automatically sorted by filters
- Relative Paths can be relative to macros such as $(VCInstallDir)
- Not easy to use
- Can create files relative access paths only
- Can create access paths relative to Project/Compiler/System and SourceTree or absolute paths
- Can’t easily edit file locations
- Can create files relative access paths only
- Can create access paths relative to Project/Compiler/System and SourceTree or absolute paths
- Can’t easily edit file locations
- Access paths can be recursive or not
- Divided into user/system, even though it’s not relevant for source files
- Access paths can be relative to Project/Compiler/System/Source Tree or absolute paths
- Can create source trees as relative to environment variables, registry keys, or absolute paths
- Source Tree list per project or global.
- Because recursive access paths are parsed shielded folders are used
- VS Filters only sort linked resource added to the project.
- CW linked resource quite flexible
- VS Filters only sort linked resource added to the project.
- CW linked resource quite flexible
- VS Filters only sort linked resource added to the project.
- CW linked resource quite flexible
- VS Filters only sort linked resource added to the project.
- CW linked resource quite flexible
- VS Filters only sort linked resource added to the project.
- CW linked resource quite flexible
- VS Filters only sort linked resource added to the project.
- CW linked resource quite flexible
- No use of new features? No problem. Old API works with new projects using groups/linked..
- Groups revert to directories
- Portable Linked Resource are broken
- Resource Filters are ignored
- Not synchronized, virtual, logical folders
- Can’t create normal files/ folder under a group
- Drag and drop within the resource explorer also is linked resource / group aware
- Not portable = useless
- Projects now have path variable list.
- Linked Resources uses variable relative location
- Can use macros in path variables values
- PARENT ${PARENT-COUNT-VAR}
- Extensible path variables
- Can refer to legacy workspace path variables
- Can use macros - ${PARENT-COUNT-VAR}
- Extensible path variables
- Can refer to workspace variables
- Can use macros - ${PARENT-COUNT-VAR}
- Extensible path variables
- Can refer to workspace variables
- Scalability (large directories don’t cause thousands of objects to be loaded)
- Flexibility (can customize which files/folders are present)
- Include Only
- Applies to Files/Folders
- Doesn’t apply to linked files / folders
-Exclude All
-Inherited
- More pervasive use of linked resources
- IResource.getLocation() == null
- Resource explorers and drag and drop