Home » Modeling » EMF » Projects compatibility
| |
| Re: Projects compatibility [message #415180 is a reply to message #415177] |
Tue, 04 December 2007 11:20   |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Paverz,
Normally if you ensure that you introduce only binary compatible changes
in your model, i.e., only add new types of thing and features to
existing things, you should be able to read old files easily. For
example, even though Ecore has evolved significantly we can still read
the .ecore files produced by EMF 1.0. With options like
XMLResource.OPTION_RECORD_UNKNOWN_FEATURES you can even support the case
where an older application can read newer files, recording the things it
doesn't recognized and obviously not allowing you to edit it, and then
reinjecting it on save. This approach can also be useful if you break
the serialization, i.e., remove things or change their names, because it
allows you to analyze the unrecognized content and migrate it. If you
do something to completely change the serialization, you'd likely want
to change the namespace of your model, and keep an old dynamic version
around to be able to read old instances and transform them into new ones
much like UML has done a few times; you could use an Ecore to Ecore map
to help with this type of approach.
PC wrote:
> Hi,
>
> Just wondering what’s the right approach in eclipse/emf based
> application for projects compatibility in different versions of an
> application?
>
> We are developing an eclipse based application where data is in emf
> models either stored in files or in db using teneo.
> The user should be able to open project/files/data with new version of
> application which might be created with older version of our
> application. Just like any other application for example normally a
> user can open word doc in current version which might be created with
> old version of MS Word.
>
> Is there some feature in emf which we can use? or should it be done
> fully programmatically case by case basis i.e. writing code in next
> version of application to read file depending upon what has changed in
> current as compare to earlier versions like addition of attribute in a
> class, new class etc.
> Any suggestion will be helpful.
>
> Thanks.
> - Parvez
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Projects compatibility [message #415181 is a reply to message #415180] |
Tue, 04 December 2007 12:01 |
Parvez
Messages: 181
Registered: July 2009 |
Senior Member |
|
|
Hi Ed Merks,
Thanks for the information and good to know about
XMLResource.OPTION_RECORD_UNKNOWN_FEATURES for forward compatibility.
I guess it is difficult to see at this stage what will change in future
version of application. Though new additions are obvious but due to
refactoring/redesign of existing models, the existing
classes/attributes/names are likely to change and I guess we can't do
much till we reach that stage.
I will look into ecore2ecore map, are there any tutorials for this or
whatever I can find in eclipse help ref?
Thanks.
- Parvez
Ed Merks wrote:
> Paverz,
>
> Normally if you ensure that you introduce only binary compatible changes
> in your model, i.e., only add new types of thing and features to
> existing things, you should be able to read old files easily. For
> example, even though Ecore has evolved significantly we can still read
> the .ecore files produced by EMF 1.0. With options like
> XMLResource.OPTION_RECORD_UNKNOWN_FEATURES you can even support the case
> where an older application can read newer files, recording the things it
> doesn't recognized and obviously not allowing you to edit it, and then
> reinjecting it on save. This approach can also be useful if you break
> the serialization, i.e., remove things or change their names, because it
> allows you to analyze the unrecognized content and migrate it. If you
> do something to completely change the serialization, you'd likely want
> to change the namespace of your model, and keep an old dynamic version
> around to be able to read old instances and transform them into new ones
> much like UML has done a few times; you could use an Ecore to Ecore map
> to help with this type of approach.
>
>
> PC wrote:
>> Hi,
>>
>> Just wondering what’s the right approach in eclipse/emf based
>> application for projects compatibility in different versions of an
>> application?
>>
>> We are developing an eclipse based application where data is in emf
>> models either stored in files or in db using teneo.
>> The user should be able to open project/files/data with new version of
>> application which might be created with older version of our
>> application. Just like any other application for example normally a
>> user can open word doc in current version which might be created with
>> old version of MS Word.
>>
>> Is there some feature in emf which we can use? or should it be done
>> fully programmatically case by case basis i.e. writing code in next
>> version of application to read file depending upon what has changed in
>> current as compare to earlier versions like addition of attribute in a
>> class, new class etc.
>> Any suggestion will be helpful.
>>
>> Thanks.
>> - Parvez
|
|
|
| Re: Projects compatibility [message #415182 is a reply to message #415181] |
Tue, 04 December 2007 12:51 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Parvez,
Sorry for butchering your name. I'm not sure if Kenn ever wrote a
tutorial/paper for the Ecore to Ecore and Ecore to XML support. He uses
it in UML2 so at least that's an functional example...
PC wrote:
> Hi Ed Merks,
>
> Thanks for the information and good to know about
> XMLResource.OPTION_RECORD_UNKNOWN_FEATURES for forward compatibility.
>
> I guess it is difficult to see at this stage what will change in
> future version of application. Though new additions are obvious but
> due to refactoring/redesign of existing models, the existing
> classes/attributes/names are likely to change and I guess we can't do
> much till we reach that stage.
> I will look into ecore2ecore map, are there any tutorials for this or
> whatever I can find in eclipse help ref?
>
> Thanks.
> - Parvez
>
> Ed Merks wrote:
>> Paverz,
>>
>> Normally if you ensure that you introduce only binary compatible
>> changes in your model, i.e., only add new types of thing and features
>> to existing things, you should be able to read old files easily. For
>> example, even though Ecore has evolved significantly we can still
>> read the .ecore files produced by EMF 1.0. With options like
>> XMLResource.OPTION_RECORD_UNKNOWN_FEATURES you can even support the
>> case where an older application can read newer files, recording the
>> things it doesn't recognized and obviously not allowing you to edit
>> it, and then reinjecting it on save. This approach can also be
>> useful if you break the serialization, i.e., remove things or change
>> their names, because it allows you to analyze the unrecognized
>> content and migrate it. If you do something to completely change the
>> serialization, you'd likely want to change the namespace of your
>> model, and keep an old dynamic version around to be able to read old
>> instances and transform them into new ones much like UML has done a
>> few times; you could use an Ecore to Ecore map to help with this type
>> of approach.
>>
>>
>> PC wrote:
>>> Hi,
>>>
>>> Just wondering what’s the right approach in eclipse/emf based
>>> application for projects compatibility in different versions of an
>>> application?
>>>
>>> We are developing an eclipse based application where data is in emf
>>> models either stored in files or in db using teneo.
>>> The user should be able to open project/files/data with new version
>>> of application which might be created with older version of our
>>> application. Just like any other application for example normally a
>>> user can open word doc in current version which might be created
>>> with old version of MS Word.
>>>
>>> Is there some feature in emf which we can use? or should it be
>>> done fully programmatically case by case basis i.e. writing code in
>>> next version of application to read file depending upon what has
>>> changed in current as compare to earlier versions like addition of
>>> attribute in a class, new class etc.
>>> Any suggestion will be helpful.
>>>
>>> Thanks.
>>> - Parvez
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Projects compatibility [message #415207 is a reply to message #415182] |
Wed, 05 December 2007 13:19 |
Eclipse User |
|
|
|
Originally posted by: mikael.barbero.gmail.com
Parvez,
There are some project for detecting changes and creating automatically
or semi-automatically a model transformation from the old metamodel
version to the new metamodel version (the transformation is not encoded
as an ecore2ecore map but as an ATL transformation).
Here are some use cases descriptions on these principles:
http://www.eclipse.org/gmt/amw/usecases/migration/ (simplest one)
http://www.eclipse.org/gmt/amw/usecases/compare/
http://www.eclipse.org/gmt/amw/usecases/autosar/
Hope this helps.
Best regards,
Mikael
Ed Merks wrote:
> Parvez,
>
> Sorry for butchering your name. I'm not sure if Kenn ever wrote a
> tutorial/paper for the Ecore to Ecore and Ecore to XML support. He uses
> it in UML2 so at least that's an functional example...
>
> PC wrote:
>> Hi Ed Merks,
>>
>> Thanks for the information and good to know about
>> XMLResource.OPTION_RECORD_UNKNOWN_FEATURES for forward compatibility.
>>
>> I guess it is difficult to see at this stage what will change in
>> future version of application. Though new additions are obvious but
>> due to refactoring/redesign of existing models, the existing
>> classes/attributes/names are likely to change and I guess we can't do
>> much till we reach that stage.
>> I will look into ecore2ecore map, are there any tutorials for this or
>> whatever I can find in eclipse help ref?
>>
>> Thanks.
>> - Parvez
>>
>> Ed Merks wrote:
>>> Paverz,
>>>
>>> Normally if you ensure that you introduce only binary compatible
>>> changes in your model, i.e., only add new types of thing and features
>>> to existing things, you should be able to read old files easily. For
>>> example, even though Ecore has evolved significantly we can still
>>> read the .ecore files produced by EMF 1.0. With options like
>>> XMLResource.OPTION_RECORD_UNKNOWN_FEATURES you can even support the
>>> case where an older application can read newer files, recording the
>>> things it doesn't recognized and obviously not allowing you to edit
>>> it, and then reinjecting it on save. This approach can also be
>>> useful if you break the serialization, i.e., remove things or change
>>> their names, because it allows you to analyze the unrecognized
>>> content and migrate it. If you do something to completely change the
>>> serialization, you'd likely want to change the namespace of your
>>> model, and keep an old dynamic version around to be able to read old
>>> instances and transform them into new ones much like UML has done a
>>> few times; you could use an Ecore to Ecore map to help with this type
>>> of approach.
>>>
>>>
>>> PC wrote:
>>>> Hi,
>>>>
>>>> Just wondering what’s the right approach in eclipse/emf based
>>>> application for projects compatibility in different versions of an
>>>> application?
>>>>
>>>> We are developing an eclipse based application where data is in emf
>>>> models either stored in files or in db using teneo.
>>>> The user should be able to open project/files/data with new version
>>>> of application which might be created with older version of our
>>>> application. Just like any other application for example normally a
>>>> user can open word doc in current version which might be created
>>>> with old version of MS Word.
>>>>
>>>> Is there some feature in emf which we can use? or should it be
>>>> done fully programmatically case by case basis i.e. writing code in
>>>> next version of application to read file depending upon what has
>>>> changed in current as compare to earlier versions like addition of
>>>> attribute in a class, new class etc.
>>>> Any suggestion will be helpful.
>>>>
>>>> Thanks.
>>>> - Parvez
--
Mikaël Barbero - PhD Candidate
ATLAS Group (INRIA & LINA) - University of Nantes
2, rue de la Houssinière
44322 Nantes Cedex 3 - France
tel. +33 2 51 12 58 08 /\ cell.+33 6 07 63 19 00
email: Mikael.Barbero@{gmail.com, univ-nantes.fr}
http://www.sciences.univ-nantes.fr/lina/atl/
|
|
|
| Re: Projects compatibility [message #415249 is a reply to message #415207] |
Fri, 07 December 2007 10:11 |
Parvez
Messages: 181
Registered: July 2009 |
Senior Member |
|
|
Thanks Ed & Mikael for information and direction. I will try to find
further information on these.
- Parvez
Mikaël Barbero wrote:
> Parvez,
>
> There are some project for detecting changes and creating automatically
> or semi-automatically a model transformation from the old metamodel
> version to the new metamodel version (the transformation is not encoded
> as an ecore2ecore map but as an ATL transformation).
>
> Here are some use cases descriptions on these principles:
> http://www.eclipse.org/gmt/amw/usecases/migration/ (simplest one)
> http://www.eclipse.org/gmt/amw/usecases/compare/
> http://www.eclipse.org/gmt/amw/usecases/autosar/
>
> Hope this helps.
>
> Best regards,
> Mikael
>
>
> Ed Merks wrote:
>> Parvez,
>>
>> Sorry for butchering your name. I'm not sure if Kenn ever wrote a
>> tutorial/paper for the Ecore to Ecore and Ecore to XML support. He
>> uses it in UML2 so at least that's an functional example...
>>
>> PC wrote:
>>> Hi Ed Merks,
>>>
>>> Thanks for the information and good to know about
>>> XMLResource.OPTION_RECORD_UNKNOWN_FEATURES for forward compatibility.
>>>
>>> I guess it is difficult to see at this stage what will change in
>>> future version of application. Though new additions are obvious but
>>> due to refactoring/redesign of existing models, the existing
>>> classes/attributes/names are likely to change and I guess we can't do
>>> much till we reach that stage.
>>> I will look into ecore2ecore map, are there any tutorials for this or
>>> whatever I can find in eclipse help ref?
>>>
>>> Thanks.
>>> - Parvez
>>>
>>> Ed Merks wrote:
>>>> Paverz,
>>>>
>>>> Normally if you ensure that you introduce only binary compatible
>>>> changes in your model, i.e., only add new types of thing and
>>>> features to existing things, you should be able to read old files
>>>> easily. For example, even though Ecore has evolved significantly we
>>>> can still read the .ecore files produced by EMF 1.0. With options
>>>> like XMLResource.OPTION_RECORD_UNKNOWN_FEATURES you can even support
>>>> the case where an older application can read newer files, recording
>>>> the things it doesn't recognized and obviously not allowing you to
>>>> edit it, and then reinjecting it on save. This approach can also
>>>> be useful if you break the serialization, i.e., remove things or
>>>> change their names, because it allows you to analyze the
>>>> unrecognized content and migrate it. If you do something to
>>>> completely change the serialization, you'd likely want to change the
>>>> namespace of your model, and keep an old dynamic version around to
>>>> be able to read old instances and transform them into new ones much
>>>> like UML has done a few times; you could use an Ecore to Ecore map
>>>> to help with this type of approach.
>>>>
>>>>
>>>> PC wrote:
>>>>> Hi,
>>>>>
>>>>> Just wondering what’s the right approach in eclipse/emf based
>>>>> application for projects compatibility in different versions of an
>>>>> application?
>>>>>
>>>>> We are developing an eclipse based application where data is in emf
>>>>> models either stored in files or in db using teneo.
>>>>> The user should be able to open project/files/data with new version
>>>>> of application which might be created with older version of our
>>>>> application. Just like any other application for example normally a
>>>>> user can open word doc in current version which might be created
>>>>> with old version of MS Word.
>>>>>
>>>>> Is there some feature in emf which we can use? or should it be
>>>>> done fully programmatically case by case basis i.e. writing code in
>>>>> next version of application to read file depending upon what has
>>>>> changed in current as compare to earlier versions like addition of
>>>>> attribute in a class, new class etc.
>>>>> Any suggestion will be helpful.
>>>>>
>>>>> Thanks.
>>>>> - Parvez
>
>
>
|
|
|
Goto Forum:
Current Time: Fri Apr 26 15:13:39 GMT 2024
Powered by FUDForum. Page generated in 0.03716 seconds |
] 
Search
Help
Register
Login
Home
