Bug 331875

Comment 1 Greg 2011-01-18 05:52:56 EST

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.

Comment 2 Ralph Gerbig 2011-01-18 07:16:58 EST

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

Comment 3 Ralph Gerbig 2011-02-02 14:49:22 EST

Better code:

--fix BUG 331875
	gmfgenModel.objectsOfType(ExpressionLabelParser)->forEach(parser)
	{
		parser.className := parser.className.concat(parser._uses->first().container().oclAsType(GenNodeLabel).visualID.toString());
	};

Comment 4 Ralph Gerbig 2011-04-25 05:37:22 EDT

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

Comment 5 Ralph Gerbig 2011-07-07 08:27:01 EDT

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.

Comment 6 Mickael Istria 2011-07-07 09:41:48 EDT

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.

Comment 7 Michael Golubev 2011-07-07 11:08:48 EDT

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.

Comment 8 Ralph Gerbig 2011-07-08 04:38:08 EDT

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.