Hi all,
Ø
[cwd] What is the use case for choosing the legacy implementation that leads to merge conflicts in team scenarios?
It makes it easier to create a template, or to share models by e-mail/bugzilla. In all team scenarios, this should indeed be avoided.
Ø
[cwd] Templates can conflict, probably requiring some kind of intelligent merging. For example, multiple templates may import the same model libraries, but the result should not repeat imports. Also, there may be more abstract/logical
inconsistencies between templates. What is the plan to help the user not create a mess from the wrong combination of templates?
One solution might be to have two kinds of “templates”: models, and model transformations. User could choose 1 model and N model transformations.
Ø
[cwd] What do you mean by generic Ecore model? Is the New Papyrus UML Model wizard going to create an EPackage? This should be an Ecore Tools responsibility. Or is this intended to be an UML model with the Ecore profile applied,
targeting code generation with UML2?
We’ve had some requests for Papyrus to be able to manipulate languages other than UML (i.e. pure EMF models). Currently, many components in Papyrus don’t support
non-UML models anyway, but since the wizards need to be rewritten, this should be considered as a possibility (for the future). The use case is still very vague, but the wizards’ architecture should at least be ready for that.
Regards,
Camille
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de Christian W. Damus
Envoyé : mardi 6 mai 2014 14:33
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] Papyrus creation Model/Project Wizard
Hi, Thibault,
I have some questions about these requirements, in-line, below.
Dear Papyrus Developers/Users,
I am working on a new Wizard plugin for Model/Project Creation in Papyrus UML.
Thus I’m currently listing all the requirements the new wizard should follow.
Here’s a list of the requirements , I have already listed :
a) Root
Element choice : the wizard should allow the user to specify the root element e.g. Package or Model
b) Model
Name : Improvement of naming option during creation e.g. the ability to set the Model name
c) Sash
Editor Mode : User should be able to choose between legacy or “1.0” mode to serialize the sashmodel
[cwd] What is the use case for choosing the legacy implementation that leads to merge conflicts in team scenarios?
d) Template
Improvement : User should be able to load multiple template currently you can create a model with only 1 template even if checkboxes allow you to pick more than 1
[cwd] Templates can conflict, probably requiring some kind of intelligent merging. For example, multiple templates may import the same model libraries, but the result should not repeat imports. Also, there may be more abstract/logical
inconsistencies between templates. What is the plan to help the user not create a mess from the wrong combination of templates?
e) Profiled
Model : User should be able to create a model with profile applied during creation
f) Generic
Model : Papyrus should allow to create a Generic Ecore Model
[cwd] What do you mean by generic Ecore model? Is the New Papyrus UML Model wizard going to create an EPackage? This should be an Ecore Tools responsibility. Or is this intended to be an UML model with the Ecore profile applied, targeting
code generation with UML2?