Thanks for your response.
Please find my comments below.
Le 06/10/2011 18:19, Philipp W. Kutter a écrit :
There are four reasons I see NOT to look into Mof2Text (Acceleo):
- GMF Tooling consists of simple models of the graphical
editor behavior, then a mapping of that to the (more complex)
models of the generated code, and from there to Java code. The
first mapping is M2M, the second M2T.
While in the past a lot of focus was on the M2T part, the
focus is now on the M2M part.
- The original architects of GMF Tooling decided to go for
XPand/XText2 family of technologies. It took a lot of effor to
migrate there, and an upgrade to the newest version of these
frameworks may be easier than Switching
- Our sponsor works with XText2, has spend money to contribute
further technology to XText2, and has made good experiences
with that technology on 50 DSLs he is working on.
I fully understand those 3 reasons.
- In a very long term view, XText2 will allow to add as well
textual syntax, and this may be one of the future topics.
Just note that Acceleo is not dependent of the syntax used to edit
see as well three reasons to look into Mof2Text (Acceleo):
Would you be ready to migrate the current templates in the newest
version of Mof2Text (Acceleo) at a given point in time?
- It is a standard like QVTO, so we would be more in synch
with the standards.
- It is a superset of OCL like QVTO, so we could profit from
experience/practice with QVT in the M2M part of GMF Tooling.
- It seems you are interested to contribute.
As your are currently working on new templates with some new
technologies you have chosen for the reasons mentioned above, I am
not sure you are currently interested by this migration.
However If you decide to switch to Acceleo, or merely use Acceleo,
at a given point in time, we could certainly help and provide
support and/or tooling to help you in the migration.
Am 06.10.2011 14:26, schrieb Mariot Chauvin:
Dear Philipp and Mickael,
In this discussion you mention several technologies that will be
used or that will be compatible with GMF Tooling.
I take the opportunity to mention the qualities of Acceleo,
a powerful model-to-text technology.
I think the new GMF Tooling may use Acceleo for the following
If you want to know more about Acceleo, you may have a look to this
presentation made during Code Generation 2011.
Let me know if you have any question.
Le 05/10/2011 08:18, Philipp W. Kutter a écrit :
Thanks for the great input, an sorry it has not been answered.
I am creating the draft proposal of the project plan
now, will commit it shortly and post the main proposed
topics here for discussion.
I am sure, Michael Golubev will start posting the topics soon.
One reason he has not published a lot is that what they work
on are topics already discussed, decided and published by
Artem, and all the earlier team members, such as using M2M to
map from graphical-editor-models to models of the code.
I think some of the topics we should think about
improving, according to what we can read on the forum are:
* Integration with CDO/Dawn
* integration with EEF to provide also customization of
properties. Not make a strong dependency of GMF-Tooling
onto EEF, but making it easier for people to think about
using EEF when developing diagrams.
We brought up CDO/Dawn as well, and it is of course planned to
do whatever is needed to support the success of CDO/Dawn.
As well, any framework like EEF, or the established way of
adding OCL to annotations, as shown by Christian Damus, or the
new way of using the new extension points for this shall work
together with GMF.
In general, the direction is that the use of GMF together with
frameworks that base on the EMF level, such as CDO/Dawn, or
EEF, or OCL, or XText2 goes smoothly.
Anything going against it, or any needed change shall be
entered as bugzilla. Have you identified any issue regarding
the integration with CDO/Dawn or EEF?
Also, technical stuff:
* Make GMF-Tooling models and templates extensible in order
to be able to provide new features in models from extension
mechanism. (Such as SVG will come with extension for the
model + extension for the templates + extensions for the
Better extensibility is the main topic. Again here, there is
started work, comming both from earlier GMF Tooling work, as
well as from work done in the MDT UML2 Tooling project where
Michael Golubev was the component lead.
Please provide some trust to the people who worked on the GMF
Tooling project and related topics for 10+ years now.
Besides coding, the team will provide a library of reusable
"Diaglets" that show how to use all the extension mechanisms,
and how diagramming elements can be made reusable.
I +1 this proposal. Until then, GMF-Tooling release and
versioning was trying to follow the same rythm than
GMF-Runtime, but the last monthes clearly show that the
project cannot really work like this any longer. Then it
would make a lot of sense to start a new 3.x stream with
lots of new features.
However, it is already clear for me that in order to
deliver the new features we need Juno release to be a
major one, thus 3.0 instead of 2.x.
The reason is, we will have to change models
significantly, and we will not be able to provide
automatic backward compatibility with the models created
(we will of course follow the transition procedure
from the past of GMF-T and will develop 'Migrate Model'
actions to support migration of existing models).
As mentioned, the main topic is extensibility and
reuseability. But I expect as well of a few new features.
The idea is however, that new features can be contributed by
the community as "Diaglets" of code, that uses the better
extendability and reuseablity of the code.
GMF Tooling shall become a model-case of using EMF technology
to create extensible and reusable functionality. Core of this
is the ability to extend the most intelligent part of the
code, which transforms the model representing the
graphical-editor into the models representing the final code.
The way to make this extensible is by using a M2M technology,
in our case QVTO.
Then the resulting code shall be structured such, that it is
easy to customize using the results of the M2M transformation,
and that it is easy to reuse.
I hope this answers some questions.
gmf-dev mailing list
gmf-dev mailing list
Philipp W. Kutter
CEO, Dr. sc. ETH
tel: +41 44 260 75 57
mob: +41 79 338 06 17
The contents of this email and any attachments are
confidential. They are intended for the named
recipient(s) only. If you have received this email by
mistake, please notify the sender immediately and do not
disclose the contents to anyone or make copies thereof.
gmf-dev mailing list