When generating code for an NMF metamodel that references classes in another metamodel which is not a loaded assembly, the code generator will apply ModelRepresentationClassAttribute corresponding to the LostProperties Uri and not the actual model Uri.
To reproduce this issue, run Ecore2Code as follows with the attached files (change .txt to .nmf): Ecore2Code.exe -f -x -n MetaModels -r http://example.com/MetaModels/ModelA/=.\ModelA.nmf -o . .\ModelB.nmf. This will result in [ModelRepresentationClassAttribute("http://example.com/MetaModels/ModelA/#//ReferencedClass#//ReferencedClass")] instead of [ModelRepresentationClassAttribute("http://example.com/MetaModels/ModelA/#//ReferencedClass")].
So far I've been able determine this is the result of the generator first deserializing ModelB then adding the LostProperty entry for http://example.com/MetaModels/ModelA/#//ReferencedClass which subsequently is used when deserializing/resolving every class in ModelA. It's likely an order of operations issue that could be resolved by generating and loading ModelA first as hinted in #44 but it's not clear to me at this point. @georghinkel Any ideas where to go with this one?
When generating code for an NMF metamodel that references classes in another metamodel which is not a loaded assembly, the code generator will apply ModelRepresentationClassAttribute corresponding to the LostProperties Uri and not the actual model Uri. To reproduce this issue, run Ecore2Code as follows with the attached files (change .txt to .nmf):
Ecore2Code.exe -f -x -n MetaModels -r http://example.com/MetaModels/ModelA/=.\ModelA.nmf -o . .\ModelB.nmf
. This will result in[ModelRepresentationClassAttribute("http://example.com/MetaModels/ModelA/#//ReferencedClass#//ReferencedClass")]
instead of[ModelRepresentationClassAttribute("http://example.com/MetaModels/ModelA/#//ReferencedClass")]
.So far I've been able determine this is the result of the generator first deserializing ModelB then adding the LostProperty entry for http://example.com/MetaModels/ModelA/#//ReferencedClass which subsequently is used when deserializing/resolving every class in ModelA. It's likely an order of operations issue that could be resolved by generating and loading ModelA first as hinted in #44 but it's not clear to me at this point. @georghinkel Any ideas where to go with this one?
ModelA.txt ModelB.txt