Hi,
To elaborate on the composability of products, I think that a part of the answer to this requirement will be provided
by the ongoing work on architecture frameworks.
You may find further information on this work here
https://wiki.eclipse.org/Papyrus/Oxygen_Work_Description/NewFeature/PapyrusAFViewpointSwitch
Long story short, this feature will help in partitioning the various Architecture Context (namely the various Architecture
Frameworks and Architecture Description Languages) and to switch from one to another.
By the way, I would like to encourage anyone to comment this proposal as it will be very structuring for Papyrus in terms
of user experience and for Papyrus Product design.
The wording we adopted is the ISO42010 one. Note that it is a work document. Feel free to comment using the Discussion
tab of this wiki page but please don’t edit directly the page.
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 17:42
À : Papyrus Project list <mdt-papyrus.dev@xxxxxxxxxxx>
Cc : Dr.-Ing. Stephan Thesing <Stephan.Thesing@xxxxxxxxxx>
Objet : Re: [mdt-papyrus.dev] Papyrus Extenssions/Components/companions.ADd-ins/Other?
Thanks Floriant,
Some comments inline below.
Charles Rivet
Senior Product Manager, Papyrus-RT product lead
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
<cr>
Please note that “Papyrus for UML” is already defined as part of the Papyrus IC Product Management Committee work done during the Ericsson Modeling days. I would like to confirm whether or not we are talking about the
same product.
From a product Management point of view (as I can’t talk for the Papyrus IC PMC), having a uniform branding strategy is an important factor in marketing the Papyrus (or any, for that matter) product line. As such, I would
strongly recommend keeping the “for” for all products, for the reasons stated in a previous response to Sébastien.
</cr>
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.
<cr>
</cr>
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.
<cr>
I like this, both from an infrastructure and a marketing point of view.
</cr>
Don’t hesitate to react to my mail. The first proposal of this refactoring will be proposed very soon.
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:
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?
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.
Charles Rivet
Senior Product Manager, Papyrus-RT product lead
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".
Back from EclipseCon Europe, where we had a shared stand with Polarys and Capella with a nice demo of Moka and Designer with Nao, and the talk of Francis on Papyrus IC [0],
I would like to know if you have a proposition to name the Papyrus ToolSmith. [1]
I have opened a ticket here [2]
My pesonla preference ToolSmithS / tss
Thanks for your feedback.
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
|