Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [Edapt] One ecore file extended with other ecore files
| [Edapt] One ecore file extended with other ecore files [message #1072176] |
Mon, 22 July 2013 08:38  |
 Cedric Moonen
Messages: 274
Registered: August 2009 |
Senior Member |
|
|
Hello,
I have an ecore model, which contains a couple of interfaces. These interfaces can be implemented via other ecore files from other plugins (this way, our models can be extended by providing a separate plugin). Now, I need to have the ability to migrate those models whenever there's a change (in the core domain model or in the other ecore models).
Unfortunately, Edpat doesn't support such a scenario: I could only handle the core model changes. Somebody else already posted something about that here: http://www.eclipse.org/forums/index.php/m/1038552/?srch=Edapt#msg_1038552.
I have something to suggest for that issue, but I'm not sure if it is feasible to implement (I don't have access to the source code to verify that). The ReleaseUtils.getNamespaceURI method could in fact return a list of all model URI's which are used, then you could have separate histories for each separate domain models. This way, you could invoke all migrators independently. However, as I said, I have no clue if something like that is feasible (I don't know how the migration is implemented internally).
Of course, supporting changes that span multiple ecore models won't be feasible, but at least more use cases could be covered compared to the current scenario.
BTW, is there a way to get readonly access to the Edapt sources ? There's a SVN repository but it requires user name and password. I would like to have a look at the code and possibly implement some ideas there if this is not too complex. Then I oculd possibly submit a patch if other people are interested.
Thank you,
Cédric
|
|
|
| Re: [Edapt] One ecore file extended with other ecore files [message #1072286 is a reply to message #1072176] |
Mon, 22 July 2013 13:06  |
Maximilian Koegel
Messages: 253
Registered: July 2009 |
Senior Member |
|
|
Hi Cédric,
the code moved to git just recently in an effort to configure a build
for Edapt at Eclipse.org and improve its maintenance:
http://git.eclipse.org/c/edapt/org.eclipse.emf.edapt.git/
Edapt supports a shared history, spanning multiple Ecores. Separate
histories would not allow connected changes between different Ecores to
be tracked correctly to my understanding.
Internally Edapt uses changes recorded during editing an Ecore to derive
the migration steps. For example renaming an attribute in the Ecore will
create a migration step to rename the attributes of all instances in an
existing model that conforms to the given Ecore.
If you contribute an improvement I am happy to assist, review and commit
the contribution.
Cheers,
Maximilian
Am 22.07.2013 10:38, schrieb Cedric Moonen:
> Hello,
>
> I have an ecore model, which contains a couple of interfaces. These
> interfaces can be implemented via other ecore files from other plugins
> (this way, our models can be extended by providing a separate plugin).
> Now, I need to have the ability to migrate those models whenever there's
> a change (in the core domain model or in the other ecore models).
> Unfortunately, Edpat doesn't support such a scenario: I could only
> handle the core model changes. Somebody else already posted something
> about that here:
> http://www.eclipse.org/forums/index.php/m/1038552/?srch=Edapt#msg_1038552.
>
> I have something to suggest for that issue, but I'm not sure if it is
> feasible to implement (I don't have access to the source code to verify
> that). The ReleaseUtils.getNamespaceURI method could in fact return a
> list of all model URI's which are used, then you could have separate
> histories for each separate domain models. This way, you could invoke
> all migrators independently. However, as I said, I have no clue if
> something like that is feasible (I don't know how the migration is
> implemented internally). Of course, supporting changes that span
> multiple ecore models won't be feasible, but at least more use cases
> could be covered compared to the current scenario.
>
> BTW, is there a way to get readonly access to the Edapt sources ?
> There's a SVN repository but it requires user name and password. I would
> like to have a look at the code and possibly implement some ideas there
> if this is not too complex. Then I oculd possibly submit a patch if
> other people are interested.
>
> Thank you,
> Cédric
--
Maximilian Kögel
Get Professional Eclipse Support: http://eclipsesource.com/munich
|
|
|
| Re: [Edapt] One ecore file extended with other ecore files [message #1072328 is a reply to message #1072286] |
Mon, 22 July 2013 14:35 |
Cedric Moonen
Messages: 274
Registered: August 2009 |
Senior Member |
|
|
Hi Maximilian,
Thanks for the reply.
Quote:the code moved to git just recently in an effort to configure a build
for Edapt at Eclipse.org and improve its maintenance:
http://git.eclipse.org/c/edapt/org.eclipse.emf.edapt.git/
That's nice, I'll have a look at the code when I have a bit of time.
Quote:Edapt supports a shared history, spanning multiple Ecores. Separate
histories would not allow connected changes between different Ecores to
be tracked correctly to my understanding.
Yes, I was aware that option, but in my case, I have one central ecore files and multiple ecore files which "extends" this central model (they are totally unrelated). So, in my case this solution won't work.
As I said, I'm aware that having separate histories won't allow tracking changes over multiple files, but in my specific case, most of the time the changes will be local to an ecore file.
Quote:If you contribute an improvement I am happy to assist, review and commit
the contribution.
It's not on the planning right now but if I have the opportunity to look at the code and find a solution for my problem, I'll keep you informed.
Thanks,
Cédric
|
|
|
Goto Forum:
Current Time: Thu Apr 25 04:46:57 GMT 2024
Powered by FUDForum. Page generated in 0.03282 seconds |
] 
Search
Help
Register
Login
Home
