Hi,
I just noticed that my first reply does not appear in the
modeling-pmc archives. I’m not sure I it reached anybody, so I just mail my
answer again.
Regards,
Michael
Hi all,
sorry for the late reply, but we first
needed to have some team-internal discussions on this which could only be done
now as all team members are back from their holidays now - and German Christmas
and New Years holidays are traditionally long... ;-)
We placed our proposal intentionally
directly under the EMP umbrella and not under GMF, because we didn't want to
create the impression that switching a tool that was generated using GMF (and
its standard runtime) to Graphiti would be very simple. Having an alternative
runtime sounds - at least to us - like it is simply done by setting another
flag somewhere and maybe trigger a re-generation and that's it. But that's
simply not the case.
In fact, Graphiti has a completely
different approach than the GMF runtime (keyword here is features, which is the
concept to describe a certain behavior in Graphiti). In general the needed
runtime artifacts differ quite a lot from what is needed for GMF. Actually, I'm
not really sure if the information collected inside the GMF metamodels is
sufficient to generate a tool upon the Graphiti framework; additional
information might be necessary whereas existing information in the GMF
metamodels might not be useful at all for Graphiti generation.
An additional argument for not being
placed under the GMF project is the fact that GMF is very much based upon the
generation of tools, whereas Graphiti is intended to be a runtime API the user
codes against. We have had our own internal approaches with generated tools
inside SAP and always ended at a point where the generation approach came to an
end and hand-crafting was necessary again. And manually adapting generated
coding can be very awkward. In our opinion, the generation of tools is great
for easy tools or for showcases and demos, but real tools offering increased
value and high usability to end-users will, in our view, need manual coding.
Because of that, the generation of tools
is not in the focus of the Graphiti project at all. Of course it would be
possible to add it on top but that is not our short- or mid-term intention. But
being an additional runtime for GMF would require just this very soon.
On the other hand we can also understand
the argument of polluting the Modeling Project with yet another graphical
framework. From that aspect we would vote for a kind of umbrella project as Ed
has suggested. Nevertheless, we cannot judge what that would mean from the
administrative point of view...
Any comments or suggestions welcome.
Two question in the end:
1) What would it mean for us as a
project if we become a sub-subproject underneath such an umbrella project (or
the GMF project) instead of being a subproject underneath EMP?
2) Should this discussion be continued
here or shouldn't it be shifted to the Modeling Forum?
Kind regards,
Michael
Michael Wenz
Senior Developer
TD Core JS&I DPI (AG)
SAP AG
Dietmar-Hopp-Allee 16
69190 Walldorf, Germany
T +49 6227 7-61613
F
+49 6227 78-27044
E
michael.wenz@xxxxxxx
www.sap.com
Pflichtangaben/Mandatory
Disclosure Statements: http://www.sap.com/company/legal/impressum.epx
Diese E-Mail kann Betriebs-
oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten.
Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine
Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail
ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die
empfangene E-Mail. Vielen
Dank.
This e-mail may
contain trade secrets or privileged, undisclosed, or otherwise confidential
information. If you have received this e-mail in error, you are hereby
notified that any review, copying, or distribution of it is strictly
prohibited. Please inform us immediately and destroy the original transmittal.
Thank you for your cooperation.