|Schema location for cascaded ecore models "initialize by loading" [message #987614]
||Tue, 27 November 2012 10:35
I have 2 Ecore models A and B which use the "initialize by loading"
option. The B model extends classes from A.
I have altered each loadPackage() to call createResource() with the URI
of the packageFilename.
But when I serialize an instance of model B, a proper schema location is
only emitted for model B. When I load the resulting .xmi file into the
generic EMF editor it chokes on unknown features which stem from model A.
1) Is this supposed to work as I have described? What could I have
2) Is there any way to register the static EPackages with the package
filename URI WITHOUT having to touch generated code? I _really_ like
being able to wipe all *.java files, refresh and regenerate.
|Re: Schema location for cascaded ecore models "initialize by loading" [message #987696 is a reply to message #987651]
||Tue, 27 November 2012 16:13
| Ed Merks
Registered: July 2009
On 27/11/2012 1:35 PM, Marius Gröger wrote:
> On 27.11.2012 11:55, Ed Merks wrote:
>> On 27/11/2012 11:35 AM, Marius Gröger wrote:
>>> I have 2 Ecore models A and B which use the "initialize by loading"
>>> option. The B model extends classes from A.
>>> I have altered each loadPackage() to call createResource() with the URI
>>> of the packageFilename.
>> What does these URIs look like?
>>> But when I serialize an instance of model B, a proper schema location is
>>> only emitted for model B. When I load the resulting .xmi file into the
>>> generic EMF editor it chokes on unknown features which stem from model A.
>> It will save a schema location only if the resource's URI is different
>> from the nsURI.
> I know about the uri vs nsURI thing and have thus modified the static
> packages accordingly. That changed URI looks fine and points to the
> .ecore file.
Yes, that's what it sounds like.
> Actually I think I found the root cause: when using the "initialize by
> loading" option, a copy of the original .ecore is placed inside the src
> directory where the generated sources are.
> This happens for both my model A and B. But that generated .ecore for
> model B does not know the location of the generated .ecore of model A.
No, it refers to the other model via its nsURI.
> The issue shows already when I open the generated .ecore for model B: it
> complains that I has no knowledge of model A.
Yes, it's intended for loading at runtime only by the generated package
> So it appears I need to modify the generated code even more to let it
> point to some common directory containing all related models. Which is
> not so easy at all since A and B are in different plugins.
The original Ecore files along with their GenModels are generally
available at runtime as well. They can generally be accessed by
Powered by FUDForum
. Page generated in 0.02079 seconds