Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: for the plan.

Jump to: navigation, search


< E4‎ | Resources‎ | Meeting
Meeting Title: E4 Resources meeting
Date & Time: Friday Apr 3, 2009 at 1500 UTC / 11am EST / 8am PST
Ical.gifiCal,Xml.gifATOM News Feed,Html.gifHTML
Canada and US Toll Free: (866) 740-7083
International Dial-in: +1 (702) 696-4217 (more numbers here)
Conference ID: 613 277 0037 #


  • Call is Open, Anybody can join.
  • Attendees
    • Wind River - Doug Schaefer, Martin Oberhuber
    • IBM - John Arthorne, Szymon Brandys
    • Freescale - Serge Beauchamp
    • Embarcadero - Kenn Hussey


Feel free to edit, but not during the meeting

Review of Action Items


  • Doug : e4 resources presented by Mike Milinkovich at Members Meeting : Multi Workspace
    • bug 245399 multi workspace - John is interested and may start investigating in summer when there is more time
      • Resources is pretty much ready to support this... but in the field, there is a lot of ResourcesPlugin.getWorkspace()
      • ResourcesPlugin.getWorkspace() could return the default workspace, while others could get to other instances
    • Martin is really interested in user-side requirements that people want to address with multi workspace:
      • for instance: working on multiple branches of the same project - namespace resolution
      • might be solved with different technical approaches, e.g. logical project nesting or "solutions" as groups of projects - it's just a matter of scoping for name resolution
        • Serge is interested in solving "multiple projects with same name in a workspace"
      • today, a workspace is just (a) a collection of projects plus (b) settings and preferences. We might find different means of solving the real user problems.
        • Project References are the biggest problem with respect to name collisions in a workspace - must find a scoping solution
        • Serge is interested in project references pointing outside the workspace
        • Martin - project reference information could be some kind of PATH rather than just a name, or name + hints for disambiguation

Modeled Resources

  • Eclipsecon
    • Serge got feedback that people are interested in flexible resources work
    • Doug got feedback from Cisco interested in e4 enhancements for CDT specifically for scaling up to HUGE workspaces
    • Doug would like to see the e4 resources team grow - there have been around 1000 attendees at Eclipsecon
    • Kenn had discussion with people asking why there wasn't a model for the resources API's - Kenn is interested AI Kenn create a bug for channeling discussions around this
      • Especially meta-info about resources (how they are related with each other, properties of resources, build info, ...)

RESTful Resources

  • Martin RESTful principles for Resources
    • A lot of work has happened in EMF to make the infrastructure more RESTful, e.g. not assume a filesystem, ...
    • EMF now allows registering handlers for various events that need to happen when opening resources: content types, URI, open handlers, ...
    • Clients to inject handlers to tweak the way it operates
    • Martin: EFS experience has shown that transparently replacing handlers is not enough... clients implicitly assume that resources are fast and reliable. We may need new APIs
      • Resources using visitor pattern a lot today... any ideas about making those RESTful, e.g. stateless query with asynchronous response rather than visitor pattern
    • Martin: could we use separate layers, e.g. core resources as we have them today, and above that a NEW layer that provides RESTful APIs and/or modeling of properties
      • Kenn: in a real RESTful world there are only very few concepts and operations: URIs (relative and absolute); URIs relative to each other may be seen as related to each other
      • No concepts of "project" or "folder", that's an implementation specific thing
      • RESTful layer could be compatible or orthogonal to "current Eclipse" way of doing things: EFS filesystem could be one mapping of things; another mapping could be for projects/files/folders
    • Kenn is interested in collaborating with others on RESTful for resources
      • Chris and the RDT people should be interested - AI Martin to inquire
    • John thinks that what Kenn talks about is similar to what Chris and the RDT folk are exploring... with the client having some "Resources Model"
      • John thinks that a whole "Resources Server" would make more sense, with RESTful APIs on top of it rather than below it ... doing all the heavy lifting on the server
      • The question is really where to draw the line between client and server
    • Doug thinks there may be different cuts into the architecture
      • AI Martin create a bug for tracking REST discussion

Common Navigator

  • Common Navigator Situation
    • Serge: Improve CN resources plugin to support drop adapter assistants; JDT would need to be updated to properly delegate DND to the CN framework
    • Martin seems to remember that Francis proposed waiting with an e4 fork of CN resources until M7 when bulk of the bugfix work on CN is done in the 3.x branch
    • Tracking on bug 269404

JDT and e4

  • JDT and e4
    • Is JDT staffed enough to do e4 ? How to do the self-hosting until e4 0.9 ?
    • John: there is two questions - (a) e4 self-hosting and (b) what happens in 3.6 -- the 3.6 planning process is currently ongoing
      • How much do we need to do in JDT in order to support e4 resources; for instance, DND support in the package explorer
      • One solution could be just using the project explorer and not doing the package explorer -- Francis working on feature parity with package explorer in M7 anyways
      • As long as no filters / groups / etc are created, there should not be any impact anyways
    • Martin: Because of Java Language spec, JDT is tightly coupled to file system anyways and wouldn't want to use much e4 stuff
      • Maybe some classpath stuff

Action Items

  • (old) Martin create SearchCVS service for e4 resources - started on database, query missing AI mail e4-dev
  • (old) Martin send a proposal regarding experimental API tagging policy to the e4 mailing list - pending bug 261874 AC discussion about provisional API
  • (old) Ken put references to bugs which are interesting for him into the meeting notes
  • (old) Ken have somebody from Symbian Foundation comment on bug 249745 regarding their experiences with git and Mercurial
  • Kenn to create bug for modeled resources
  • Martin to ping Chris Recoskie
  • Martin to create bug for RESTful resources discussions

Next Meeting

Back to the top