Dear all,
All your comments are aligned with our current refactoring of Papyrus’ architecture.
I like the “Papyrus Extension”.
Just as a complement, each of the future Papyrus top and sub projects may release multiple Papyrus Extensions and/or Papyrus
Product.
Regarding Papyrus Platform, today, we plan to release ‘Papyrus UML’ (or ‘Papyrus for UML’, the name has not been chosen
yet) as a Papyrus Product and ‘Papyrus for Toolsmith’ (or what will be chosen) as a Papyrus Product.
All the extra plugins in Papyrus main repo will be moved to the appropriate or a new repo (until we have a sub-project
for them).
In our understanding of Papyrus Product, we expect to provide something downloadable in the form of an RCP (or alike)
for it while Papyrus Extensions will be features (according to Eclipse’s wording) that anyone can install from any Papyrus Product. It will be up to each sub project to decide if their Extension is worth the release of a Papyrus Product but we expect that
every Papyrus Product will release a corresponding Papyrus Extension.
On this topic, the “Install Papyrus Additional Components” will evolve to reflect this new organization. Also, while Papyrus
Team used to maintain the various extras for each release, Papyrus Products and Papyrus Extensions will have their own roadmap. We even think of removing this “Papyrus market place” in favor of a new category (probably named “Papyrus”) in Eclipse marketplace.
This would simplify the release of extensions and the maintenance of this marketplace.
Don’t hesitate to react to my mail. The first proposal of this refactoring will be proposed very soon.
Best regards.
/Florian
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de charles+zeligsoft.com
Envoyé : jeudi 3 novembre 2016 16:43
À : Papyrus Project list <mdt-papyrus.dev@xxxxxxxxxxx>
Objet : Re: [mdt-papyrus.dev] Papyrus Extenssions/Components/companions.ADd-ins/Other?
+1
That and companions are replaced but the Doctor stays… ;-)
Indeed, to me ‘companion’ suggests an additional tool that runs separately, not integrated into Papyrus. I would steer well clear of that! 😉
On 3 November, 2016 at 11:31:48, charles+zeligsoft.com (charles@xxxxxxxxxxxxx)
wrote:
From a marketing perspective, I like "Papyrus Companion” as it helps with the anthropomorphized approach taken in the blog and on twitter - but that, in itself,
is not a valid reason for the selection of the term we use (plus, I can work around it ;-).
For the reasons he lists below, I like Christian’s suggestion of "Papyrus Extension.”
Charles Rivet
Senior Product Manager, Papyrus-RT product lead
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?
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.
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
_______________________________________________
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
_______________________________________________
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
|