Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-papyrus.dev] [Documentation] Mixing main and extra plugins documentation

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

 

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Christian Damus
Envoyé : mardi 28 juin 2016 15:21
À : Papyrus Project list <mdt-papyrus.dev@xxxxxxxxxxx>
Objet : Re: [mdt-papyrus.dev] [Documentation] Mixing main and extra plugins documentation

 

Hi, Mauricio,

 

See some replies in-line, below.

 

Christian

 

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.

 


 

Any ideas?

 

Cheers!

Mauricio Alférez, PhD

Research Engineer

Commission for Atomic Energy and Alternative Energies (CEA)

Direction of Technological Research (DRT)

Systems and Technology Integration Laboratory (LIST)

Software and Systems Engineering Department (DILS)

Model-driven Engineering for Embedded Systems Laboratory (LISE)

 

[1] \git\org.eclipse.papyrus\plugins\doc

[2] \git\org.eclipse.papyrus\features\papyrus-main-features\org.eclipse.papyrus.doc.feature\feature.xml

[3] https://en.wikipedia.org/wiki/Feature_model

[4] \git\org.eclipse.papyrus\features\papyrus-main-features

[5] \git\org.eclipse.papyrus\features\papyrus-tests-extra-features

[6] https://en.wikipedia.org/wiki/Aspect-oriented_software_development

_______________________________________________ 
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


Back to the top