| Schema location for cascaded ecore models "initialize by loading" [message #987614] |
Tue, 27 November 2012 10:35  |
Eclipse User |
|
|
|
Hello,
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
forgotten?
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.
Best Regards
Marius
|
|
|
|
| Re: Schema location for cascaded ecore models "initialize by loading" [message #987651 is a reply to message #987623] |
Tue, 27 November 2012 12:35  |
| Eclipse User |
|
|
|
On 27.11.2012 11:55, Ed Merks wrote:
> On 27/11/2012 11:35 AM, Marius Gröger wrote:
>> Hello,
>>
>> 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.
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.
The issue shows already when I open the generated .ecore for model B: it
complains that I has no knowledge of model A.
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.
Regards
Marius
|
|
|
| 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
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Marius,
Comments below.
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:
>>> Hello,
>>>
>>> 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.
Yes.
>
> 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
implementation.
>
> 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
platform:/plugin/<plugin-id>/model/<ecore-file-name>.ecore.
>
> Regards
> Marius
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.02884 seconds
] 
Search
Help
Register
Login
Home
