GMF Dev Call 20070410
The following issues were discussed during our second GMF Dev Call. This was a follow up call from the one held March 21st:
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.
RESOLVED 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?
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.
WONTFIX 174498 - .trace will work for now, not sure why it's still open? Linda realized here why trace functionality is "experimental" :) Can close.