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?

157188 - Introduced with another bug fix (112998). Will fix.

159289 - look at proposed approach for 152445. There is a way to do it, but same issue as above - shouldn't need to remove items.

150257 - Mohammed will look at when gets back.

150408 - Mohammed

154748 - Mohammed - an ugly workaround present, part is platform issue

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).

Should be assigned to someone other than Radek?

133505 - Mohammed (canonical)

129533 - Not planned for this release. Artem to add detail re: use of unique ids, as he recalls it was part of the original conversation.

146535 - related to link source/target bug - tough to describe in the model, without making too complex. No time yet to think through. Documentation would be reasonable here as well.

Linda - without children or containment, generation does not work. Artem: Generator needs to be updated to add passthrough for this case.

174503 - Custom templates is easiest approach, currently. Too many places contributing icons already (runtime, emf.edit), so would prefer to avoid a third.

Linda: looking to add icon for semantic elements not in emf.edit (specializations). Will need to think of adding attribute to overrride current, but default to emf.edit

174490 - Not too important, can be worked around (code modification) - better option is to customize template.

174494 - Same type of issue

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.

174498 - .trace will work for now, not sure why it's still open? Linda realized here why trace functionality is "experimental" :) Can close.