+1 for me as long as the OCL project still provides a feature dedicated
to the core runtime, this project his consumed by many adopters as a
pure runtime framework and not as a tooling provider. Both the tooling
versus runtime should be kept in separate artefacts to ease adoption.
Cédric
Le 01/07/2010 01:14, Kenn Hussey a écrit :
+1
Ed, can you direct us to the location of the existing scope
document? I looked for the original project proposal for EMFT OCL but
was unable to find it...
Kenn
On Wed, Jun 30, 2010 at 4:02 PM, Ed Merks <ed.merks@xxxxxxxxx>
wrote:
+1
So I think you need to edit the existing scope document then ask the
EMO to formally update it.
Ed Willink wrote:
Hi
The MDT/OCL project was originally set up to support the OMG OCL
meta-model and _expression_ evaluation. The MDT/OCL has also provided an
'example' OCL console supporting interactive evaluation for at least
three years.
An MDT/OCL Tools project was proposed to provide editors and code
generation, but failed to reach the creation review.
An OCL editor has bounced from GMT/UMLX (SWT-based) via M2M/QVTd
(IMP-based) to MDT/OCL examples in Helios, where IP issues required a
late redevelopment to be Xtext-based.
Xtext provides a dramatically simpler and arguably much better parser,
which merits revisiting many of the internal models so that the
official OCL specification validation and well-formedness constraints
can be used and debugged rather than paraphrased. However use of
interpreted OCL is liable to give very disappointing performance, so
Java code generation from OCL becomes important to MDT/OCL itself. Java
code generation is also important to capitalize on the support for OCL
delegates that EMF added in Helios.
Xtext is an excellent example of the new generation of modeling tools
that really add model-driven value. With the aid of QVTo and Acceleo,
Java code generation should be much more disciplined and tractable.
It therefore makes sense to add generation of code from OCL and OCL
editing within the scope of the MDT/OCL project rather than
rejuvenating the failed MDT/OCL Tools project. With the advent of
tooling, it would seem appropriate for MDT/OCL to emulate MWE with
multiple update site zips. An OCL-Core build at +1 would continue to
offer the basic meta-model and evaluation support. A second OCL-Tools
build at +3 would provide the functionality currently lurking as
MDT/OCL examples without the dilemma of releasing examples at +1 with
+3 dependencies.
In summary, is it alright for MDT/OCL to expand its scope to code
generation from OCL, to OCL editing and to interactive OCL evaluation?
Regards
Ed Willink
_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
|
