+1
Yes, the idea was to have a complete doc of Papyrus including its extra features in order Papyrus users may know what
exist and what to do to get the feature if not yet installed. In other case, you need to install the feature to know the feature is existing…
|
|

|
|
|
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
T. +33 1
69 08 45 19
sebastien.gerard@xxxxxx
www-list.cea.fr
|
|
|
|

|
|
|
|
|
|
|
|
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de MAGGI Benoit
Envoyé : mardi 28 juin 2016 15:53
À : Papyrus Project list <mdt-papyrus.dev@xxxxxxxxxxx>
Objet : [PROVENANCE INTERNET] Re: [mdt-papyrus.dev] [Documentation] Mixing main and extrapluginsdocumentation
Hi,
From what I understood it’s for marketing reason, to promote extra in the core feature.
I asked the same question some time ago [1] and here is the whole discussion [2]
Regards,
Benoit
1:
https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/msg02295.html
2:
https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/msg02310.html
See some replies in-line, below.
On 28 June, 2016 at 09:13:08, ALFEREZ SALINAS Edward Mauricio (mauricio.alferez@xxxxxx)
wrote:
Dear Papyrus Developers,
Senior Papyrus architects most probably know the answer to my question, but I would like to ask (again?): Is there any good reason to mix the documentation of
the main and extra plugins? This phenomenon manifests in two ways: (1) physically, in the directory “doc” [1] where there are *.doc plugins of extra and main plugins, and (2) logically, in the org.eclipse.papyrus.doc.feature feature plugin [2].
Someone may argue that the reason to mix main and extra plugins documentation is to promote the extras by packaging their documentation to all users --even if
they don’t install or want to install any extra—.
This was the main point of the explanation when I asked the same question. 😉
Or, perhaps not so much “promotion” as just letting users be aware of what capabilities there are that may be of use to them.
However, I believe that this may not be a good way to go because of two main reasons:
- It
may break the notion of “feature” supported by the entire Eclipse ecosystem (i.e., a feature is “a unit of separately downloadable and installable functionality”).
I agree. Documentation should be published and installed together with the software; an installation should not document capabilities that it has not implemented.
- It
breaks the principle of separation of concerns used in Software Engineering. In our case the concerns are– mandatory functionality represented by the main features located in “papyrus-main-features” vs optional functionality represented by extra features that
should be located in the “Papyrus extras” [5]. In fact, this issue is not new and has been studied by feature modeling [3], and aspect-oriented software development [6].
Well, I don’t know about that. Documentation is not software, so the separation of concerns doesn’t really apply. But, I think it is sufficient that Papyrus advertises a Component
Discovery function that provides awareness of and access to these extra components. If the description of the capabilities of these various components in the discovery index isn’t good enough to let users know how useful a component may be in his or her work,
then that should be fixed.
I would like to see the documentation for the extras packaged together with those features in the Extras repository, factored out of the main distribution.