The Oomph setup model can help a good deal with this, too, to make functional groupings of projects clear through Working Sets. Currently, working sets collect together the plug-ins of a component, the features of that component, and the tests of that component into distinct working sets. And documentation plug-ins are all lumped together into a single working set.
Perhaps instead we should be grouping all of the projects for a component, the plug-ins, tests, features, and docs, together into a single working set for that component. I’d be interested to hear from the rest of the team what this organization should look like. Keeping in mind, of course, that working sets don’t nest and that the setup model can only provide one scheme for everybody.
In any case, ideally the workspace setup should be able to make the filesystem layout of the git repository immaterial to how we understand the organization of the code.
Christian
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) <image002.jpg> 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 | 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 ?
|
