Bugzilla – Full Text Bug Listing
| Summary: | "Create undefined" in create context menu | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] GMF-Tooling | Reporter: | Ralph Gerbig <ralphgerbig> | ||||||
| Component: | Core | Assignee: | Project Inbox <gmf-runtime-inbox> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | major | ||||||||
| Priority: | P3 | CC: | benjaminschwartz, borlander, mistria | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Ralph Gerbig
Created attachment 201301 [details]
Screenshot
is the label correcly set in the domain model? If you mean the feature name in the ecore file, it is correctly set. I cannot find a label property in the ecore and generator model. The name of corresponding IElementType is shown here, you might check and correct it in the element type extension of the plugin.xml. You shoul dsee the same Undefined's in the popap bar for the container that may contain the end nodes of this link. I am closing the bug as WoksForMe, although its not clear why the element type was not choosen correctly (as it normally should be at least for nodes, while may experience legitimate troubles with feature links). I think this is related to tooling either the transformation to the genmodel or the template extensions.xpt whith this definition. # Providers «EXPAND internal_i18n FOREACH getAllTypedElements().elementType» «ENDDEFINE» «DEFINE internal_i18n FOR gmfgen::ElementType-» «IF null <> displayName and not definedExternally»metatype.name.«diagramElement.getUniqueIdentifier()»=«displayName»«ENDIF» «ENDDEFINE» I think we should certainly fix to have undefined as the default value in the genmodel. This would allow users to still override the display name. This would fix the issue to have undefined as default value. I can try to propose a patch if others think it makes sense. Think it is a bug related to tooling. This property is already editable in the property sheet for gmfgen, so user already able to override that in UI Thats true. But I think that having Undefined in there is the bug. Created attachment 201857 [details]
Patch
Hi,
I created this patch based on a custom template that worked for me. However, I am not able to get this debugged in my target workbench.
Ralph
Committed patch, works locally, waiting for the IC test to remain blue. Not resolved any more! Problem patch is commented out. Patch is working, but I couldn't see a reason for the comment. (In reply to Benjamin S. from comment #11) > Patch is working, but I couldn't see a reason for the comment. Try "git blame" on this file, it will show you as part of which commit this got commanded and hopefully the commit message will give you the reason. I traced the commits back... First commit was 0242d4345f0391d77a11abd3e3db0d3d8fa4011d to Map2Gen.qvto 5a9aeaf4527a9557ec6f8e927f2a090b91089e88 moved helper to Map2GenUtil.qvto Refactor commits: fa2e9f4fe44fb57aeaa17bd7ddb47014db6a5b33 deleting helper methods in Map2GenUtil.qvto d831103ebfc6ac30d04519cf6d43dddc56090c49 adding methods again into Mappings.qvto Commit message was: Rewrite the mapping of CompartmentMapping, previous usage of Tuples throws IllegalArgumentException under OCL 4.0.0 The commented sections has nothing to do with this commit message. In my opinion just a copy-paste mistake, however this happens. Just curious that nobody spotted it the last 2 years... I will take a look, also it is difficult for me to relate the commit you found with this problem.
For now I would like to repeat the workaround:
>> The name of corresponding IElementType is shown here, you might check and
>> correct it in the element type extension of the plugin.xml.
|