[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [mdt-papyrus.dev] Notes of the preccomitting meeting
- From: Thibault LANDRE <thibault.landre@xxxxxxxxxxxxxx>
- Date: Wed, 12 Nov 2008 20:26:30 +0100
- Delivered-to: email@example.com
- Organization: Atos Origin - Systems Integration
- User-agent: Thunderbird 184.108.40.206 (Windows/20070326)
After reading again my previous answer, I saw that I didn't fully answer
to Cédric :
I don't mind renaming those plugins ;) There are here for development
purpose to help developers by generating code for Papyrus. So they need
to be as understandable as possible for the developpers.
I think oep.codegen is ok. Codegen refers to "Code Generation" and it is
For the oep.def, you're right, it is not clear enough. Why not
oep.TemplateGen or oep.GenTemplate instead (or others) ?
Etienne Juliot a écrit :
My opinion:In my opinion, it is not necessary to use several template directories.
- yes, we want to have a clean architecture, without too much element
forced by framework constraints
- but if there are some name conventions or plugin organisations we
don't know how to do with GMF and generators constraints, lets be
realist and use them, but with keeping in mind to improve them by submit
feature request to these frameworks to allow to use several Template
I think it is clearer to have all the templates in the same place. But
you're right, we can raise a feature for this against GMF and discuss it
But I currently lack arguments to open this feature and I don't see well
what will be the benefits of it.
Do you have arguments that I can push forward to initiate the discussion ?
For the moment, I see :
- possibility to add different templates coming from different project
(ex: Templates from Papyrus and Templates from Moskitt Project). But
this could be dangerous, I think, if the two projects work on the same
- a clearer organisation.
Any other ideas ?
- for IP submission, I think we can to NOT include these generatos, if
there are several problems. It will not be a problem for end users.
I agree. These generators are not necessary for the submission.
- for Properties generators, as Acceleo 4 will be based on MTL (OMG's
standard, like UML), I think the easiest way to commit them will be to
use this new engine already included in Eclipse Foundation. But it's too
early to speak about that, during this rush for IP submission.
Thibault LANDRE a écrit :
I know that Papyrus is different from GMF and from UML2Tools.
The GMF Papyrus generator are an extension of the GMF tool to simplify
the work for Papyrus developers. Those two plugins will be used only
OAW is used because some templates from GMF have to be overriden and
those template are done with OAW.
More, it is necessary to keep the same folder hierarchy than the bundle
"org.eclipse.gmf.codegen" to override existing templates.
Besides, to take into account the new templates defined, it is necessary
to defined the property "Template Directory" with the parent folder
containing all specific templates.
I don't know how to indicate more than one "Template Directory"
Additionnally, I don't think that it will change anything for the
developpers to have an unique plugin well structured (templates are
organized with folders int this plugin) instead of several plugins
with few templates in each one...
That's some of the reasons why I think it will be difficult to divide
into several plugins the generators...
For Properties, I know that generators exist. But as far as I know
(because I have never seen them, they are not present on the CEA svn),
they are realized with Acceleo and not OAW.
GERARD Sebastien 166342 a écrit :
I second the comment of Cedric. It is clear that Papyrus is different
from the UML2 MDT Tool, is clearly that Papyrus do not force the
usage of the GMF generator._______________________________________________
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx
[mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Cedric
Envoyé : mercredi 12 novembre 2008 16:04
À : thibault.landre@xxxxxxxxxxxxxx; Papyrus Project list
Objet : Re: [mdt-papyrus.dev] Notes of the preccomitting meeting
Thibault LANDRE wrote:
The idea was good, but we are not a GMF demonstrator :-). They have
named their plugins like that because they are gmf centric. This is
not our case.
I have named the plugin like they were denominated in the GMF and
UMLTools project (for the same functionnality).
I have kept this naming to avoid confusion for developers familiar
with GMF and UMLTools.
GMF is just a tool that we use to produce diagrams. The artefact used
for the generation should not appear abruptly in the plugins. And for
me the names of the plugins should gives clear indication of their
purpose/contents. 'def' and 'codegen' are not meaningful for me. This
is why they should be renamed.
Also, we may have such def/codegen for properties, diagrams and
others. How we will do ? Mix all the stuff in the same 'def' plugin ?
I think it is a bad idea.
mdt-papyrus.dev mailing list
mdt-papyrus.dev mailing list
mdt-papyrus.dev mailing list
org:Atos Origin - Agence Sud-Ouest ;Systems Integration
adr;quoted-printable;quoted-printable:5, avenue Albert Durand ;;Batiment A=C3=A9ropole ;Blagnac;Midi-Pyr=C3=A9n=C3=A9es;31701;France
note;quoted-printable:D=C3=A9veloppement durable, anticipons pour notre avenir / Sustainibility=
, advance our future=0D=0A=
P N'imprimez ce mail que si n=C3=A9cessaire / please consider your enviro=
nmental responsibility before printing this e-mail.=0D=0A=
Ce message et les pi=C3=A8ces jointes sont confidentiels et r=C3=A9serv=C3=
=A9s =C3=A0 l'usage exclusif de ses destinataires. Il peut =C3=A9galement=
=C3=AAtre prot=C3=A9g=C3=A9 par le secret professionnel. Si vous recevezc=
e message par erreur, merci d'en avertir imm=C3=A9diatement l'exp=C3=A9di=
teur et de le d=C3=A9truire. L'int=C3=A9grit=C3=A9 du message ne pouvant=C3=
=AAtre assur=C3=A9e sur Internet, la responsabilit=C3=A9 du groupeAtos=
Origin ne pourra =C3=AAtre recherch=C3=A9e quant au contenu de cemessage=
. Bien que les meilleurs efforts soient faits pour maintenir cette transm=
ission exempte de tout virus, l'exp=C3=A9diteur ne donne aucunegarantie=C3=
=A0 cet =C3=A9gard et sa responsabilit=C3=A9 ne saurait =C3=AAtre recherc=
h=C3=A9e pour tout dommage r=C3=A9sultant d'un virus transmis.=0D=0A=
This e-mail and the documents attached are confidential and intended sole=
ly for the addressee, it may also be privileged. If you receive this e-ma=
il in error, please notify the sender immediately and destroy it. As itsi=
ntegrity cannot be secured on the Internet, the Atos Origin group liabili=
ty cannot be triggered for the message content. Although the sender endea=
vours to maintain a computer virus-free network, the sender does notwarra=
nt that this transmission is virus-free and will not be liable forany dam=
ages resulting from any virus transmitted.