[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.omelet] Re: Current State of Omelet

Pepe Iborra wrote:

Would you mind to provide a summary of the current state of the Omelet framework? I have seen an updated version in the Eclipse Update Site, and it looks quite different to 0.0.2


Certainly. The following is updated from a reply on omelet-dev on 15-Jan-2005.

At the beginning of the year, I put all the code I've been working on for the
last few months back in CVS as OMELET 0.1.0, but have yet to upgrade the major
documentation, and so have not released it as an installable feature.

There is now some support for EMF, which provides e.g. some XSD/Rose to XMI
transformations. There is a disciplined threading policy allowing multiple
transformations to operate in concurrent threads. There is now a distinction
between a transformation (that changes the meta-model) and a conversion
(that doesn't); e.g. UML to Ecore is a transformation while File to Stream
to XMIResource is a conversion. A model can therefore have many representations
with conversions between available and a required representation performed
automatically. In order to isolate the framework requirements from user code,
the information for each representation is provided by a manifestation that
is an unconstrained choice of user class.

I started using Java generics to improve the coding reliability, and found
that they gave me a lot of trouble; you just cannot do C++ style traits.
So a fair number of usages got unwound.

Anyway, OMELET 0.1.0 supervises a number of useful transformations, but not
sufficient to allow me to use OMELET for any of my applications. So since I
cannot use OMELET, I cannot really recommend anyone else to.

I have now written some XSLT (NiceXSL) transformations that support conversion of
XMI 1.0/1/2 to XMI 2.0, and MOF 1.3/4 to MOF 2.0, and UML 1.3/4/5 or MOF 2.0 to
Ecore. I have gathered together a number of UML/MOF meta-models and translated
them to Ecore so that these transformations validate themselves for at least
the syntax sub-set suitable for meta-modelling. I am mining translations
from EMF/XSD/UML2 and making these available as transformations.

These transformations enable me to use Poseidon's XMI 1.2 as a meta-modelling front
end for EMF, and I am now defining the OMELET registration model as an
omelet.xml file rather than a plugin.xml so that OMELET registrations can
occur in the current OMELET session, rather than a nested Eclipse session within
which OMELET is debugged.

I have made useful progress with Tefkat and ATL, using the example
meta-models as part of my transformation test cases. The OMELET namespace
registry has been upgraded to define the background EMF URI-mapping so
that registration of models in OMELET enable the EMF Sample Ecore Editor
to resolve to URLs correctly and so show Tefkat models usefully.

This will all be available in OMELET 0.1.1 which is awaiting license clarification;
the Tefkat license prohibits promotion, so releasing the OMELET Tefkat support is a problem.

I am currently able to make trivial use of OMELET. As soon as the omelet.xml is
operational in place of plugin.xml, I will rejuvenate some broken code for cascaded
transformations, and provide some useful examples. At this point I think OMELET
will become useful and the bandwagon can start to roll.