Community
Participate
Working Groups
Build Identifier: 20100917-0705 I have a node with two labels. To each of them a expression label with an OCL expression is mapped. I would expect that for each label the mapped expression is executed. Instead the second expression is executed for both labels even though it is not mapped to the first diagram label and the first expressuion is not executed. Reproducible: Always Steps to Reproduce: 1. Add two expression label mappings for two different diagram labels to a node mapping in gmfmap 2. Only the second expression is executed for both labels instead of the first expression for the label where it is mapped to and the second for the label where it is mapped to.
I've also encountered that problem. I checked to find the source of the error and found it in "project name".gmfgen. Both these expression labels get a "Expression Label ... Parser" there (See "Gen Editor ...diagram"->"Gen Parser ...ParserProvider"). The attribute "Class name" of these parsers is not formed as "Node name" + "Label name", or any other way to distinguish them, but always gets the name "Node name" + 'LabelExpressionLabelparser'. When code generation starts it obviously will overwrite the first class when generating the second one since they do have the same name. This should also happen if you use more than two expression labels and you should always get the same result in all labels. As a workaround I manually renamed the class name in these parsers and repeated the code generation. Unfortunately these changes are undone once you start the transformation process and you have to repeat the workaround.
Hi Greg, thank you for identifying the source of the error. I could create a rather simple workaround that works. Use this qvt expression as post reconcile transformation: modeltype GMFGEN uses gmfgen('http://www.eclipse.org/gmf/2009/GenModel'); transformation postRec(inout gmfgenModel : GMFGEN); main() { --fix BUG 331875 var i = "a"; gmfgenModel.objectsOfType(ExpressionLabelParser)->forEach(parser) { parser.className := parser.className.concat(i); i := i.concat("a"); }; } Ralph
Better code: --fix BUG 331875 gmfgenModel.objectsOfType(ExpressionLabelParser)->forEach(parser) { parser.className := parser.className.concat(parser._uses->first().container().oclAsType(GenNodeLabel).visualID.toString()); };
(In reply to comment #3) > Better code: > --fix BUG 331875 > gmfgenModel.objectsOfType(ExpressionLabelParser)->forEach(parser) > { > parser.className := > parser.className.concat(parser._uses->first().container().oclAsType(GenNodeLabel).visualID.toString()); > }; Must be changed to parser.className.concat(parser._uses->first().container().oclAsType(GenCommonBase).visualID.toString()); in order to work with connections.
Created attachment 199257 [details] Patch that places the VisualId of the edit part behind the parser Patch that places the VisualId of the edit part behind the parser Could not test it as I always get a out of memory exception when trying to generate a generator model in my target workspace. Maybe someone els can test it. The idea is to put the VisualID of the LabelEditPart that uses it behind its class name. This way more than one expression labels can be created for the same mapping.
Created attachment 199263 [details] Test failures report The provided patch causes about 20 tests to fail. Either the change really break something, or it has side-effects that needs the tests to be changed, that means that it changes the expected behavior of the generator. It cannot be integrated as it. After the release, we'll discuss on whether we should adapt the tests and the current expected behavior to fix it. If you have another idea on how to fix it, feel free to provide another patch. If it keeps tests green, it will be integrated immediatly.
I will look at it, but I am not a big fun of changing the names of classes, because it breaks all of the @generated not code in the clasees that already had been generated. I would prefer to make the rename only for the second, third, etc labels.
Hi, I think renaming only the second, third label can break existing code as well. That comes as you never can assure which one is the first, second etc. How will you ensure that the one label coded against will always be the first one and hence not renamed? I think that the order is some kind of random? Even my approach with the visual Ids can break as it can happen for them to change. Ralph (In reply to comment #7) > I will look at it, but I am not a big fun of changing the names of classes, > because it breaks all of the @generated not code in the clasees that already > had been generated. > I would prefer to make the rename only for the second, third, etc labels.
