Provisioning

Paul will create feature patches such that e4 resource stuff can be dropped into 3.5 stream builds

Releng - Paul Webster about 70% done, based on CBI, expect downloadable builds + update site for resources by end next week

org.eclipse.ui.ide is shared between e4 UI work and e4 Resources work. May lead to conflits as we can't be compatible with e4 and 3.5 at the same time. Splitting UI.IDE was discussed such that the e4 UI can do its own stuff in its own plugins. A split could be done in the 3.5 Stream too. Can we move resource related UI into a separate plugin?

John: ui.ide plugin is already resources factored out from the rest of UI... probably not more to factor out, the impact of modeled UI on the ui.ide plugin will probably be pretty small... but too early right now to assess. At the moment, the org.eclipse.ui.ide plugin is in the "resources" branch only.

Discussion

Michael: If Preferences, Properties, Build Settings, Compiler Options, ... all use one common "modeled" mechanism e.g. based on EMF, then it would be possible to have one common mechanism for sharing. Could even think about database queries, tables etc... multi-changes based on queries and more advanced stuff... we might want to come up with a more general mechanism for things e.g. based on OQL

Martin: modeled "core" sounds very interesting, but it will be a challenge to come up with a UI to reflect these in an easy manner... would need some "why" reasoning that shows users why a setting is the way it is

Michael: Preferences Default: cannot see if any field is unset (i.e. pick up the default) or happens to be set to the default... also, every little tool does their own thing. We need a common mechanism to deal with layered systems and defaults.

Martin: Modeled Preferences system could also lead the way towards Policies/User roles, allowing admins to limit what users are allowed to set/change

Michael: Prefs should be in the non-UI layer.. that's currently not being discussed by the "modeled UI" folks.

John: OSGi Preference mechanism already has a good model of Preferences on Core level; the trick is the semantics of association, relating preferences with each other ("if A is set to 1.5 then B,C,D must be enabled"). That's what should be modeled in non-UI.

AI Martin file a bug against E4/Resources, requesting a uniform mechanism for describing Preferences relationships and storing that data in a uniform way (above OSGi Preferences).

John: ResourcesPlugin "Workspace" != Platform.instanceLocation "Workspace" which spans all plugins. Splitting those two concepts should be interesting. This would allow switching "Resources" Workspace without shutting down Eclipse and thus be much faster

Terry: Google tends to have large projects, not-so-large workspaces. Metadata being corrupted is a problem... decoupling might help

Michael: Metadata is not transactional, if Eclipse gets into a deadlock while writing metadata it's in an inconsistent state

Terry: No clean separation between metadata written by users and "generated" metadata