Community
Participate
Working Groups
GMF-Tooling relies on a forked XPand for code generation. This fork should be removed, and instead it the "official" XPand should be used.
I am not sure exactly why the fork had been done, but I know it taken more than 2 developer months to do that. To my understanding them main reason behind was to use QVTO expressions. I am not a big fun of that decision from the past, but changing it back now would requires a) rewriting (may be partially semi-automatically, but definitely not not 100% automatically) all the templates back to xtend/xpand b) forcing users to rewrite every custom template c) providing some verification tool that confirms that the custom templates works as expected after migration At the time GMF started to use the fork I was responsible for UML2Tools templates, and was really unhappy being forced to spent weeks for items b) and c), and I got enough experience to strongly recommend to leave it as is. At least we need some reasons better than "lets just use the latest release". Regards, Michael
This idea comes to me after a discussion with Itemis guys on the Spray (equivalent to GMF-Tooling for Graphiti) mailing-list. Those guys seem to hate GMF-Tooling just because there is a forked XPand. But I was not aware of the reason why GMF forked XPand. I thought support for QVTo was built-in XPand, I didn't know that it is the core of the GMF fork of XPand. Maybe XPand will one day include support for QVTo, then we won't need this fork anymore. There is probably another way to use XPand and QVTo together, that we could use one day instead of the fork: http://wiki.eclipse.org/Model2Text_using_Xpand_and_QVT_for_Query
Reconsidering for Kepler
For plan item for Kepler release use https://bugs.eclipse.org/bugs/show_bug.cgi?id=386838
Since Kepler SR2, GMF-Tooling provides set of xtend2 templates that allow to generate identical code.
