Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Ecore Inheritance in the same Namespace
Ecore Inheritance in the same Namespace [message #1818770] Fri, 27 December 2019 19:32 Go to next message
Robert Schulk is currently offline Robert SchulkFriend
Messages: 68
Registered: July 2015
Member
I have got a fairly large ecore model.
Now, I need the same model again, but with a slight change in its content (one reference shall point to a different class).

So basically like this:

ModelA:
ClassA
=> myRef (reference to class X)
(...) many more classes

ModelB:
ClassA
=> myRef (reference to class Y)
(...) the same classes as A


My initial idea was to create a base-ecore model from which both: ModelA and ModelB inherit. The only problem is, that I need to read in existing XML files which were created with ModelA. Referencing a base-ecore would always require to use a different namespace, correct? Is this possible in a different way?
Re: Ecore Inheritance in the same Namespace [message #1818782 is a reply to message #1818770] Sat, 28 December 2019 07:28 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30916
Registered: July 2009
Senior Member
Yes, every Ecore model needs a unique nsURI, so refactoring a model into different EPackages isn't generally going to make an older serialization readable against a pre-refactored model.

What if any is the inheritance relationship between X and Y?

One approach is to keep the older model around as a dynamic model and read older serializations based on that. Then you can transform the instance from the old model to the new model (with a new nsURI) on the fly..
Re: Ecore Inheritance in the same Namespace [message #1818784 is a reply to message #1818782] Sat, 28 December 2019 09:12 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6595
Registered: July 2009
Senior Member
Hi

The strictness and consequence of inflexibility of metamodels is perhaps their greatest weakness for which a number of tools have some accommodation. e.g Epsilon's migrate language, ATL's nsURI blindness, QVTo's non-strict, Edapt.

Your particular change to a single reference looks like it might have a simple common abstraction solution. However, I suggest you step back and consider how, now that you have one requirement for for a flexibility, you will accommodate your next ten such requirements. In particular identify what is absolutely guaranteed not to change and factor that out as a common facility while other things support an appropriate variation point.

As Ed M points out, loading the 'wrong' metamodel can be facilitated by a dynamic copy of the 'wrong' metamodel. If your usage is critical you could even have static variants of both/all. Converting between similar metamodels is quite easy in Java where the EcoreUtil.Copier can have a basic override to accommodate the regular 'copy' policy and a few variants to handle the irregularities. Doing the same with modeling tools is disappointingly hard.

Alternatively if the variations are manageable you can avoid creating 'wrong' objects and copying to 'correct' objects by using the XML loader's support for recording unknown features so that where possible the 'correct' objects are loaded directly; you just have to fix up the obsolete usage from the unknown feature reports.

Regards

Ed Willink
Re: Ecore Inheritance in the same Namespace [message #1818790 is a reply to message #1818782] Sat, 28 December 2019 12:10 Go to previous messageGo to next message
Robert Schulk is currently offline Robert SchulkFriend
Messages: 68
Registered: July 2015
Member
>What if any is the inheritance relationship between X and Y?

The elements are unrelated in terms of class hierarchy. Actually, what we are doing is to remove featuremaps from the model to be compatible to CDO.


>One approach is to keep the older model around as a dynamic model and read older
>serializations based on that. Then you can transform the instance from the old
>model to the new model (with a new nsURI) on the fly..

That would mean, that I do not generate code for the old ecore, correct? Then I would need to map the content via some reflection mechanism to my actual classes? This sounds quite complicated.

One approach that worked for me is to simply pre/post process my XML Files with a DOM parser to remove/add the required namespace. Not very pretty, but does the job as far as I can see.
Re: Ecore Inheritance in the same Namespace [message #1818791 is a reply to message #1818784] Sat, 28 December 2019 12:29 Go to previous messageGo to next message
Robert Schulk is currently offline Robert SchulkFriend
Messages: 68
Registered: July 2015
Member
Hi Ed Willink,


>(...) for a flexibility, you will accommodate your next ten such requirements. In
>particular identify what is absolutely guaranteed not to change and factor that out as
>a common facility while other things support an appropriate variation point.

That is a valid point. We did exactly that and went quite well so far! Unfortunately, the change now is within the part that should never change :).

>Alternatively if the variations are manageable you can avoid creating 'wrong' objects
> and copying to 'correct' objects by using the XML loader's support for recording
>unknown features so that where possible the 'correct' objects are loaded directly;
>you just have to fix up the obsolete usage from the unknown feature reports.

Thats a cool feature, I did not know about that. Maybe that could be a solution for us as well.
Re: Ecore Inheritance in the same Namespace [message #1818801 is a reply to message #1818791] Sun, 29 December 2019 10:10 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6595
Registered: July 2009
Senior Member
Hi

If you like working at the DOM / XML level, there is now a more disciplined alternative for XML to XML (model) transformations.

The org.eclipse.qvtd.xml plugin of the QVTd project provides an Ecore metamodel for XML. This allows any tool that uses an XMLmodelResourceFactoryImpl rather than generically an XMlResourceFactoryImpl or specifically a MyDslResourceFactoryImpl to exploit a Resource full of EObjects, one per XML element/attribute. Programmatically you can register XMLmodelResourceFactoryImpl as a replacement resource factory for your input file extension. Interactively you may just copy/rename your file to *.xmlmodel and thereafter use any standard EMF tool.

See [1] which also describes the capabilities of the Ecore metamodel for Text in the org.eclipse.qvtd.text plugin.

Regards

Ed Willink

[1] http://www.eclipse.org/mmt/qvt/docs/OCL2018TextM2M/TextM2M.pdf
Previous Topic:Fail to get inherited EAttribute with Resource.getObject(String uriFragment)
Next Topic:EMF.Edit-based validation leads to UI freeze
Goto Forum:
  


Current Time: Sat Feb 29 04:53:51 GMT 2020

Powered by FUDForum. Page generated in 0.02017 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top