[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [m2t-dev] Xpand OCL component proposal (code migration)
|
Rich,
sorry I originally wanted to write this mail before you propose the
component. Hopefully you still welcome a discussion on this.
As said during the PMC call, I really understand your need to remove
the "Xpand variant" from GMF and I also know that it has been promised
by committers of the M2T/Xpand component to provide a working Xpand
within the ganymede release. It's really a painful situation having
this dialect within GMF, especially when people use the real Xpand and
the modified version shipped with GMF at once. This is the case for
all GMF users doing code generation with oAW (and AFAIK there are a
lot). Unfortunately having an "official" Xpand dialect in addition
would further worsen the situation.
So, I see and understand your need for a solution, but I doubt that
it's a good idea to come up with yet another template language.
We already have three languages in M2T:
- JET (the orginal solution from EMF)
- MTL (the implementation of the OMG standard, which uses OCL and Op-
QVT)
- Xpand (a practice proven solution)
Besides that you need a template language now, because you want to get
rid of the "Xpand variant" (I fully understand that), I don't see how
an "Xpand OCL" would add any value. I think there are already
solutions for everybody: If you like standards and want to be conform
go for MTL, if you like pragmatic solutions go for Xpand, if you like
Xpath go and use JET.
In case you want to migrate to the real Xpand language you can do so
by the end of this year.
As the current GMF generator is already implemented in Xpand it
shouldn't be too hard to migrate and to have everything working and
tested for the galileo release.
Note, that there is a huge user base (we've up to 70 messages a day in
our forums) and all these users will be able to use, understand and
enhance the generator shipped with GMF.
Note that TMF/Xtext's (textual equivalent to GMF) generator is also
implemented in Xpand, and we are working on combination and
integration of GMF and Xtext editors. It will be helpful if there are
not two many different technologies for the same purposes.
All in all I'ld like to see GMF migrating to M2T/Xpand. We can of
course talk about opening up Xpand so that it would be possible to use
Operational-QVT functions like Xtend functions (that really would be a
good thing!).
But it's not possible for us to just change the expression language to
OCL, because this heavily breaks API contracts.
(Don't you also have API contracts in GMF? AFAIK the current modified
Xpand shipped with GMF uses the original expression language. Doesn't
the OCL migration mean that all the templates of the users will be
broken?)
Hopefully you don't get me wrong. I definitely see your point but
coming up with an "Xpand OCL" component IMHO will definitely hurt the
acceptance of Xpand *and GMF*. And will make it more difficult to
understand and combine the different solutions.
Especially in EMP we should work on reuse and consolidation rather
than on inventing new things when there are already solutions. That
clearly means making compromises, but I'm pretty sure they are worth it.
regards,
Sven
On Aug 25, 2008, at 3:55 PM, Richard Gronback wrote:
Hello,
As discussed on the last PMC call [1], we'd like to finally get the
Xpand
variant out of GMF and into M2T where it belongs. Given the current
migration of the current Xpand to an Xtext-based foundation, and
given the
desire to continue using Xtend and underlying expression language by
the
current Xpand team, we'd like to create a new 'Xpand OCL' component
in M2T.
This version of Xpand will use OCL and QVTO for the query/expression
language, and include the enhancements made to Xpand for GMF's needs
[2],
but which were never fully implemented in the original Xpand. Also
provided
will be a migration utility that converts the use of Xtend to OCL/
QVTO. The
initial committers for this component will be Artem Tikhomirov
(lead) and
Alexander Shatalin (both GMF committers already).
Copying the GMF and M2T dev mailing lists to get approval for code
migration.
Copying the Modeling PMC to get PMC approval (obviously, my vote is
+1).
Copying the EMO to serve as indication that the obligatory community
announcement needs to be made for this new component. Actually, as
it's not
really 'new' but just relocating, is this necessary? It can't hurt, I
suppose.
Copying the IP team for confirmation to get clarification on what
moving
code from one project to another will entail, from an IP perspective.
Anything? A CQ for tracking purposes? Maybe we could use a cartoon
for
moving code between projects? ;)
Copying Bjorn as the "master of process" to help identify any
complications
the newly approved development process changes may present in this
move. I
didn't see anything specifically on this under /dev_process, but
suppose
this topic could be the first under the "I am a PMC Member..." on [3].
Thanks,
Rich
[1] http://wiki.eclipse.org/Modeling_PMC_Meeting%2C_2008-08-19
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=202813
[3] http://www.eclipse.org/projects/dev_process/index.php
_______________________________________________
m2t-dev mailing list
m2t-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2t-dev
