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—. 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”).
-
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].
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