Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

E4/Resources/Doug

< E4‎ | Resources

Here are some somewhat random thoughts and my vision for the Eclipse Resource model.

  • Backwards compatibility
    • Whatever we do we need to support 3.x plug-ins that use the public APIs properly
    • We can implement the old APIs with an adaption layer to the new APIs
  • What's a resource
    • Files that have contents we can view and edit
    • Folders that contain files and other folders
    • That's it. No more.
  • What's a Workspace?
    • List of folders we care about
    • Workspace Root is the top level folder
    • Do we need more than on root ???
      • Could be used for different views
      • working sets could be different roots
      • Not sure...
  • What's a Project?
    • Good question
    • Right now projects have natures and builders (build commands)
    • Also right now, projects are top level thing between workspace root and files/folders
    • Doesn't map well to non-Eclipse "project" concept
      • What is that anyway?
      • Project is folder where you can run make?
      • Not sure...
    • Could we move the builders to any old resource
      • So you can build a file or a folder
      • The builder can decide what that the semantics of building a file or folder are
    • What about build target?
      • In make world, different build targets can be issued in the same folder (i.e. same Makefile)
      • Not sure...
    • We need more powerful project (build?) references
      • What were references originally for???
      • We need to be able to get at build settings between projects
        • e.g. project exports an include folder, dependent projects add that folder to their include path
    • We need a common framework for build settings
      • CDT build model is such a framework
      • Configurations allow for modeling different build targets
      • The CDT build model also goes as far as being able to issue build commands by modeling input resources and output resources and the tool and option data needed to run the commands.
      • And it's not specific to C/C++, used by other languages as well
        • We could also extend the command idea to run internal commands (i.e. in plug-ins) as well as the current support for external commands.
  • Resource Deltas
    • One of the key features of Eclipse
    • Worry about scalability, would listener model be better???
  • Flexible resource
    • Resources map to file system objects
      • URLs can handle the mapping
      • Need to handle folder children
        • Need to handle automatic inclusion of new children and exclusion of children from a folder
        • Need to be able to add children to folders from any URL.
    • EFS provides the ability to map resources to things in a file system
      • Make it a first class citizen (or is it already???)
  • Team support
    • Right now CVS checks out into the resource tree
    • ClearCase Remote Client provides a better model
      • Check out into the file system
        • Can work in a navigator on the file system
      • Then import into the resource hierarchy
        • or better map using EFS

Back to the top