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

Really helpful, very appreciated.
I'm not sure if this is the normal Eclipse policy, but I get an "Access 
Forbidden" error whenever I try to access the dev mailing list archives. 
Should I subscribe and try again? I'm interested in case there is more 
documentation available about the recent Omelet developments


"Ed Willink" <ed@xxxxxxxxxxxxx> escribió en el mensaje 
news:d0l2l9$4v5$1@xxxxxxxxxxxxxxxxxx
> 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.
>
>