Thanks to all for sharing your vision on Papyrus products/extension ... I will try to gather/summarize elements at this web page [1] I would like to catch your attention on the fact that the main Papyrus feature is “badly” called org.eclipse.papyrus.sdk.feature… Francois [1]: https://wiki.eclipse.org/Papyrus#Papyrus_Ecosystems De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Christian Damus Envoyé : jeudi 3 novembre 2016 15:58 À : Papyrus Project list <mdt-papyrus.dev@xxxxxxxxxxx> Objet : Re: [mdt-papyrus.dev] Papyrus Extenssions/Components/companions.ADd-ins/Other? I agree that it is important to recognize that some Papyrus Projects (in the Eclipse sense of the organizational structure) are intended to add capabilities to other Papyrus Products (in the sense of deliverable software packages). My own preference for that is the term ‘extension’, because that is exactly what its function is: to augment the feature set of the product by means of addition. The term ‘add-in’ for me suggests something more casual, or at least not as purposefully Papyrus-oriented. So, how about distinguishing ‘Papyrus Product’ and ‘Papyrus Extension’ as two taxonomical labels for Papyrus software packages? On 3 November, 2016 at 10:43:23, GERARD Sebastien 166342 (sebastien.gerard@xxxxxx) wrote: Following this discussion (Thanks Francois ;-) and in order to fix the Papyrus Vocabulary. We have this notion of product. I see at least two categories of Product I would like to be able to differentiate. The product that are selfcontaining such as Papyrus-SysML or Papyrus-RT, and the products that are to be combined with a Papyrus (Selfcontain) Product in order to be used as for example Papyrus-DC (Diff-Compare). In that case, would it be preferable to introduce a different term such as Papyrus Companion, Papyrus Addin, Papyrus Component (I do not like this one because component term is already over used), other? | | 
| | | Sébastien Gérard Head of the LISE labs CEA Research Director Papyrus project Leader (www.eclipse.org/papyrus) 
Commissariat à l’énergie atomique et aux énergies alternatives Institut List | CEA Saclay Nano-INNOV | Bât. 862- PC174 F-91191 Gif-sur-Yvette Cedex M. +33 6 88 20 00 47 T. +33 1 69 08 58 24 sebastien.gerard@xxxxxx www-list.cea.fr | | | | 
| | | | | | | |
De : GERARD Sebastien 166342 Envoyé : jeudi 3 novembre 2016 15:34 À : Papyrus Project list <mdt-papyrus.dev@xxxxxxxxxxx> Objet : RE: [mdt-papyrus.dev] Toolsmith Good point Charles. If Papyrus succeed to become a top level project it will be product of the Papyrus Product Family. Until that, it will be a kind of sub-project of Papyrus Similarly to SysML. About the naming, we informally agree on having a long name and a short name. The short name should follow this rule (based on EBNF notation): · <Papyrus Product Short Name> = Eclipse Papyrus - <short name postfix> ð Here we should decide if we want restrict the postfix to be an acronym of 2, 3 or more letters? Or be something free including any name? · <Papyrus Product Long Name> = Eclipse Papyrus for <long name postfix> ð Questions: do we really want “for” to be mandatary? Should <long name postfix> be the expansion of the acronym? That mean that <short name postfix> should be an acronym. Other? Séb. | | 
| | | Sébastien Gérard Head of the LISE labs CEA Research Director Papyrus project Leader (www.eclipse.org/papyrus) 
Commissariat à l’énergie atomique et aux énergies alternatives Institut List | CEA Saclay Nano-INNOV | Bât. 862- PC174 F-91191 Gif-sur-Yvette Cedex M. +33 6 88 20 00 47 T. +33 1 69 08 58 24 sebastien.gerard@xxxxxx www-list.cea.fr | | | | 
| | | | | | | |
Although I like what Maximilian proposes, we need to be careful with the Papyrus branding with regards to the names we use and how we use them. In line with this, my first question is how will this be packaged? Will it be a “Papyrus Additional Component”? Or will it be a full-blown product like those defined by the Papyrus Industry Consortium (Papyrus IC), which has already done some work on consistent naming for the Papyrus product line [1] ? If this is to be the former (Additional Component), then I like Maximilian’s proposal of simply calling it “Papyrus SDK.” If the latter (product in the product line), then I would hope that it could follow the pattern established by the Papyrus IC, that is: - Long name: Papyrus for <<task/domain/user type>>
- Short name: Papyrus-<<short 2-5 characters related to Long Name>>
E.g., “Papyrus for Toolsmiths” as a long name and “Papyrus-TS” as a short name.
In this case, also, it should probably officially become part of the Papyrus IC’s Papyrus product line. [1] https://wiki.polarsys.org/Papyrus_IC/Product_Management [[SG] >] Charles Rivet Senior Product Manager, Papyrus-RT product lead Hi, I like "Papyrus for Toolsmiths", what also comes into my mind is the term "SDK" in this context. So another name could be "Papyrus SDK" or even a combination of both "Papyrus SDK for Toolsmiths".
-- Senior Software Architect / General Manager Mobil: +49 176 223 619 18 Phone: +49 89 21 555 30 - 10 Fax: +49 89 21 555 30 - 19 EclipseSource Muenchen GmbH General Managers: Dr. Jonas Helming, Dr. Maximilian Koegel Registered Office: Agnes-Pockels-Bogen 1, 80992 Muenchen, Commercial Register München, HRB 191789 _______________________________________________ mdt-papyrus.dev mailing list mdt-papyrus.dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
_______________________________________________ mdt-papyrus.dev mailing list mdt-papyrus.dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
|