Hello,
I understand that there is a necessity of placing the documentation as separate plug-ins but it is also obvious that it is making it harder to
manage as Benoit states. For instance, today I was checking plugins/doc folder but it was impossible to understand which documentations belong to extra-plugins or to locate the corresponding plugin folders. Currently, the developers need to know everything
by heart, and this can become a bigger problem as the project grows.
One solution would be organizing the plugins/doc folder with the same tree structure with their corresponding plugins. For example it can be like:
·
plugins/doc/plugins/uml/org.eclipse.papyrus.uml.doc
·
…
·
plugins/doc/extraplugins/codegen/org.eclipse.papyrus.codegen.doc
·
…
Like that it can be easier to locate the documentation of a plugin and vice versa. Any ideas?
Best,
Önder GÜRCAN
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)

Commissariat à l’énergie atomique et aux énergies alternatives (CEA)
Paris-Saclay Campus - Nano-INNOV | Bât. 862-PC1087 | F-91191 Gif-sur-Yvette Cedex
T. +33 (0)1 69 08 00 07
|
F. +33 (0)1 69 08 83 95
|
onder.gurcan@xxxxxx
|
Search Onder |
LinkedIn |
Papyrus
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de Christian W. Damus
Envoyé : vendredi 19 décembre 2014 13:23
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] [PROVENANCE INTERNET] Re: [PROVENANCE INTERNET] Re: [PROVENANCE INTERNET] Re: Documentation for plugin in plugin
Hi,
One good reason for packaging documentation separately from all of the other plug-ins is so that it can be deployed separately, for example in the Eclipse Infocenter: see bug 443315 [1].
Papyrus wasn’t contributed to help.eclipse.org in Luna; it must be in Mars. And should be for Luna SR2 also, IMO.
But I think that documentation about main plugin must be inside. In this maner maintenance can be facilitate the second reason from Benoit.
For example I have found document about sash editor done by cedric dumoulin in the directory doc. (this doc was done with the version before papyrus eclipse).
I think that It was not maintained because everyone have forgotten that a doc existed somewhere..
To my mind, it is important/critic to be able to separate each element/plugin.
A plugin should come with its own documentation, source code etc… It could live alone.
So I join Benoit’s proposition.
If you want to have doc packaged for all items/plugins, even if the plugin itself is not packaged inside the Papyrus RCP, then you have just to
write a different releng for your papyrus rcp that aggregates all documentation from all registered plugins.
I do prefer this approach.
+1. Extra plgins should also précise that they have to be added to Papyrus first to be used.
Extra-plugins can come with an installation guide, so it also makes sense to have the Documentation plug-in without having the plug-in
That was the case for example for the CSS Plug-in when it was still an extra-component, and it’s the case for CDO as well
It also gives more visibility to components when they are not installed
All documentation plugins are (or at least should )stored here : org.eclipse.papyrus\plugins\doc\*.doc
My question is : Why don’t we keep the documentation in the plugin it describes ?
For example : org.eclipse.papyrus.infra.gmfdiag.common.doc should be included in org.eclipse.papyrus.infra.gmfdiag.common
- Easier
for a newcomer to find documentation when trying to add a feature
- Easier
to think of updating the doc when its already in the workspace
- Easier
to follow impact on documentation (same dependency tree as plugins)
- Won’t
miss documentation in the build when packaging an rcp or updating plugins
The only bad thing I see is that it won’t be any more possible to create a custom rcp without documentation but who will need that ?
_______________________________________________
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