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
reasons :

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.

Regards,

Mariot

Le 05/10/2011 08:18, Philipp W. Kutter a écrit :

Dear Mickael.
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.

Great.

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 runtime).

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.

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 for 2.4.x

(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).

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.

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.