Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 325484

Summary:	Seamless M2M between Acore and Ecore
Product:	[Modeling] AMP	Reporter:	Miles Parker <milesparker>
Component:	AMF	Assignee:	Miles Parker <milesparker>
Status:	NEW ---	QA Contact:	Miles Parker <milesparker>
Severity:	enhancement
Priority:	P3
Version:	1.0.0
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:
Bug Depends on:
Bug Blocks:	318274

Description Miles Parker

2010-09-16 11:36:44 EDT

It would be extremely useful to have at least representational level mappings and user tools between Acore / MetaABM models and Ecore models. One of the great advantages of that is that we can begin to think about supporting generic EMF Model Execution outside of the ABM domain!

I've been experimenting with the Acore to Ecore part and the reverse should be pretty straightforward.

One very important thing to recognize is that in all likelihood there will not be a perfect match between the two representations. If there were, there would be little need for Acore! So complete Round-Trip would not be supported. Instead, this should probably be thought of as a mechanism whereby one could..

a) Create a complete AMF model based on an existing EMF model and then customize it for modeling domain. Eventually there would be Runtime hooks through Escape as well.
b) Create a complete EMF model based on an AMF model. This might occur automatically as part of a build step. This part would be a precursor step to a full runtime integration with EMF Ecore tools such as Editors, but also allow us to inject AMF developed logic into an EMF model == really cool.

feedback / ideas?

Comment 1 Miles Parker

2011-02-21 15:43:35 EST

I've been thinking about expanding or even replacing this to include integration between models and runtime rather than a mapping between the two. In this approach, AMF could be though of as a sort of advisor to existing EMF models. I'll followup in a separate bug.