| Thanks, Camille,
See some replies/follow-up in-line, below.
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] Indeed, this will certainly help in building models for automated testing of the editors. However, it begs the question: should there also be a share/un-share menu action that converts between workspace meta-data and workspace resource storage of the sash model for an existing model (not just new ones)? I would think so. :-) Perhaps something in the ibis-head Refactor menu.
Ø [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] Yep. The separate requirement of applying profiles to the new model could be subsumed under this as a simple example of such transformation.
Ø [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.
[cwd] I had always understood that Papyrus is (or at least intends to be) structured such that its core editing capabilities are UML-agnostic (to a large extent, it is). It wasn't clear that the scope of this enhancement included more general new-model wizard infrastructure, not just the New Papyrus UML wizard. That's clear, now.
Regards, Camille 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?
If you have more requirements that the new Papyrus Wizard should follow, I’ll be pleased to hear them, The greater number of requirements I have from beginning, the better the plugin will be. _______________________________________________ mdt-papyrus.dev mailing list mdt-papyrus.dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
|
