GMF Dev Call 20070321

The following issues were discussed during our inaugural GMF Dev Call. A follow up call will be scheduled to review the status of these, and to follow up with Mohammed who was on vacation:

Attendees

Richard Gronback

Anthony Hunter

Artem Tikhomirov

Cherie Revells

Linda Damus

Alex Boyko

Dmitry Stadnik

Alex Shatalin

Notes

159479 - Artem can provide patch if needed. Tooling doesn't like using annotations as the approach. Mohammed has task to look into this (notation metamodel extension) - will add to cc on this bug?

164491 - Tooling generates code now, seems reasonable to add to runtime. A patch was provided, and will be reviewed (assigned to Mohammed).

Note: several canonical issues already assigned to Mohammed - have a follow up 2nd week in April when Mohammed back from vacation

146774 - should be handled by EMF? ;-) For now, have an approach for plugin.xml, but need ideas for manifest. Linda suggests just not overwriting, as EMF does (not ideal). Artem suggests utilizing VCS features to merge changes, or direct generation output to file next to manifest.mf if it exists. All feel this is not critical.

174496 - Artem will fix by M6, or shortly afterwards. A more sophisticated transformation approach required to fix properly.

152445 - This request has come up before. Option: do not provide it in the runtime at all? Now, tooling has to remove it, which seems odd as it was disabled to begin with. Next release.. create a clean diagram with just add on functionality, rather than remove functionality added by default. Move these default contributions to another plugin? Take out *.diagram.ui.providers plug-in to remove all actions, then look into adding back what's there?

138442 - Changes to gmfmap needed, need to be investigated further.. not easily achieved. Can't be done by API freeze. Doesn't seem to be a popular usecase for all but complex domain modelers (e.g. UML). Now, custom templates can be used to workaround. Better documentation provided to workaround would be good.

Dmitry - generator should provide todo methods for user in these cases (that, with documentation would be best approach for now).

177797 - After switch to model-to-model transformation, utilizing that trace would be better. Current implementation is quick-n-dirty fix. We'd prefer not to make the current impl. non-experimental so as not to rely on it.