Home » Modeling » EMF » EMF Model migration dilemma.
| EMF Model migration dilemma. [message #545642] |
Thu, 08 July 2010 13:43  |
 Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
Hi There,
the nsURI of a model, is arguably the single source of information
making a model unique, right? (ok perhaps also the ns Name, but in my
case, my source model is .xsd, the targetname space would be used to
derive both the Name and ns URI of the model ).
Now to migrate a model, I believe best practise is to update the nsURI
with some revision information so like this:
http://my.company/[version]/[modelname]
Now this is fine, so a unique NS, will allow me to uniquely identify my
model, and use the two distinct models in transformations or like in the
example here:
http://wiki.eclipse.org/EMF/Recipes#Recipe:_Data_Migration
The problem with this for me is however code generation.
so when I reload my .genmodel with the latest source model (xsd), it
detects the targetnamespace change and renames the ns URI of the meta
model in the .ecore. (Which makes sense), but it also updates the
..genmodel 'Base Package'. Now this is not what I would expect, or at
least it creates some practical issues like:
1) for modified code (@generated NOT) in the .edit packages. This would
imply my customized code has also to be migrated to the newly generated
package.
2) plugin export packages have to be adapted.
Is it intended to be like this, or do I miss out on a fundamental
concept of EMF?
Cheers Christophe
|
|
|
| Re: EMF Model migration dilemma. [message #545673 is a reply to message #545642] |
Thu, 08 July 2010 14:37  |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Christophe,
Comments below.
Christophe Bouhier wrote:
> Hi There,
>
> the nsURI of a model, is arguably the single source of information
> making a model unique, right?
Yes.
> (ok perhaps also the ns Name, but in my case, my source model is .xsd,
> the targetname space would be used to derive both the Name and ns URI
> of the model ).
No, the name need not be unique.
>
> Now to migrate a model, I believe best practise is to update the nsURI
> with some revision information so like this:
>
> http://my.company/[version]/[modelname]
>
> Now this is fine, so a unique NS, will allow me to uniquely identify
> my model, and use the two distinct models in transformations or like
> in the example here:
>
> http://wiki.eclipse.org/EMF/Recipes#Recipe:_Data_Migration
Yes, that's the approach UML2 has used. In the case of Ecore itself,
we've never changes the nsURI and can still read serializations produced
by EMF 1.0.
>
>
> The problem with this for me is however code generation.
> so when I reload my .genmodel with the latest source model (xsd), it
> detects the targetnamespace change and renames the ns URI of the meta
> model in the .ecore. (Which makes sense), but it also updates the
> .genmodel 'Base Package'. Now this is not what I would expect, or at
> least it creates some practical issues like:
You've changed the target namespace in the schema? Even the GenModel
itself identifies the packages via their nsURI so when you reload but
the nsURI/targetNamespace is different, it will think the old one is
deleted/gone and you're introducing a new one. A workaround for that,
to preserve all your settings, is to change the nsURI in the *.ecore
first (to patch the renamed targetNamespace in the schema), and then do
a reload.
>
>
> 1) for modified code (@generated NOT) in the .edit packages. This
> would imply my customized code has also to be migrated to the newly
> generated package.
No, you should not need to be changing your Java package names.
>
> 2) plugin export packages have to be adapted.
That's no good either.
>
>
> Is it intended to be like this, or do I miss out on a fundamental
> concept of EMF?
The problem is that you didn't so much reload, although it obviously
looked that way, but rather you updated your GenModel to use what looks
like a completely new package. Note that you can change the Base
Package property by hand or you can use an ecore:package annotation in
the schema.
>
>
> Cheers Christophe
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EMF Model migration dilemma. [message #545683 is a reply to message #545673] |
Thu, 08 July 2010 14:58 |
Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
Ed Merks wrote:
Thanks Ed, I think the ecore:package annotation is a good solution for me!
rgds Christophe
> Christophe,
>
> Comments below.
>
>
> Christophe Bouhier wrote:
>> Hi There,
>>
>> the nsURI of a model, is arguably the single source of information
>> making a model unique, right?
> Yes.
>> (ok perhaps also the ns Name, but in my case, my source model is .xsd,
>> the targetname space would be used to derive both the Name and ns URI
>> of the model ).
> No, the name need not be unique.
>>
>> Now to migrate a model, I believe best practise is to update the nsURI
>> with some revision information so like this:
>>
>> http://my.company/[version]/[modelname]
>>
>> Now this is fine, so a unique NS, will allow me to uniquely identify
>> my model, and use the two distinct models in transformations or like
>> in the example here:
>>
>> http://wiki.eclipse.org/EMF/Recipes#Recipe:_Data_Migration
> Yes, that's the approach UML2 has used. In the case of Ecore itself,
> we've never changes the nsURI and can still read serializations produced
> by EMF 1.0.
>>
>>
>> The problem with this for me is however code generation.
>> so when I reload my .genmodel with the latest source model (xsd), it
>> detects the targetnamespace change and renames the ns URI of the meta
>> model in the .ecore. (Which makes sense), but it also updates the
>> .genmodel 'Base Package'. Now this is not what I would expect, or at
>> least it creates some practical issues like:
> You've changed the target namespace in the schema? Even the GenModel
> itself identifies the packages via their nsURI so when you reload but
> the nsURI/targetNamespace is different, it will think the old one is
> deleted/gone and you're introducing a new one. A workaround for that,
> to preserve all your settings, is to change the nsURI in the *.ecore
> first (to patch the renamed targetNamespace in the schema), and then do
> a reload.
>>
>>
>> 1) for modified code (@generated NOT) in the .edit packages. This
>> would imply my customized code has also to be migrated to the newly
>> generated package.
> No, you should not need to be changing your Java package names.
>>
>> 2) plugin export packages have to be adapted.
> That's no good either.
>>
>>
>> Is it intended to be like this, or do I miss out on a fundamental
>> concept of EMF?
> The problem is that you didn't so much reload, although it obviously
> looked that way, but rather you updated your GenModel to use what looks
> like a completely new package. Note that you can change the Base
> Package property by hand or you can use an ecore:package annotation in
> the schema.
>>
>>
>> Cheers Christophe
>>
>>
>>
|
|
|
Goto Forum:
Current Time: Thu Apr 18 16:45:39 GMT 2024
Powered by FUDForum. Page generated in 0.03894 seconds |
] 
Search
Help
Register
Login
Home
