Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[modeling-pmc] 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



Back to the top