Closed eclipse-ocl-bot closed 1 month ago
By Christian Damus on Apr 25, 2007 08:13
Why not go all the way and produce an org.eclipse.ocl.emof binding plug-in? That would be a natural home for the oclstdlib.emof. I'm not sure about putting it into the ecore plug-in, because that would be redundant with an eventual emof plug-in.
Do you mean that org.eclipse.uml2.uml is not EMOF-derived? It's UML-derived, if I understand your meaning of derived (I'm not sure that I do).
You're not duplicating anything that has already been done, no, nor anything that is on a plan.
By Christian Damus on Jun 29, 2007 13:26
An EMOF representation of the OCL Standard Library belongs in an EMOF binding, not in Ecore.
By Ed Willink on Jul 17, 2007 16:00
Agreed. INVALID rather than WONTFIX.
For the record, in order for Ecore and EMOF to be used interchangeably, loaded resources must be converted on demand to the form required. There is no need for a distinct EMOF binding, just consist EMOF support as supported by the extensible EMOF adapters in org.eclipse.gmt.umlx.common plugin.
By Ed Willink on May 27, 2011 02:48
Closing after over 18 months in resolved state.
| --- | --- | | Bugzilla Link | 183928 | | Status | CLOSED WONTFIX | | Importance | P3 enhancement | | Reported | Apr 25, 2007 03:09 EDT | | Modified | May 27, 2011 02:48 EDT | | Reporter | Ed Willink |
Description
I'm gradually fixing my EMOF serialization problems with QVT.
It would be helpful to have a org.eclipse.ocl.ecore/model/oclstdlib.emof that is the SaveAS EMOF of oclstdlib.ecore.
This provides a model containing emof:Class rather than ecore:EClass elements as required for referencing from an EMOF-derived model. Note that UML appears not to be EMOF-derived!
I'm working on an EssentialOCLResourceFactoryImpl that extends EMOFResourceFactoryImpl to provide the MDT OCL to EssentialOCL conversion when an EMOF serialisation is required. I hope I'm not duplicating something you've already done.