| Hi, Benoit,
Yes, it would be nice to have a coherent layout in git that makes it easier for an command-line aficionado to comprehend the code. But the organization of projects in the Eclipse Project Explorer also needs to make sense and does not necessarily have to correspond to the git layout. Indeed, it cannot because Eclipse projects are a flat list.
If we can recombine all of the doc plug-ins into one for easy consumption by the Eclipse InfoCenter, that would be cool. It will require aggregation of plugin.xml content and rewriting paths in the toc files in terms of the consolidated plug-in ID. But, if we’re going to do that, why not do it also for normal Papyrus installations? We want all of the documentation provided by Papyrus, even for “extra” components that aren’t installed, to be installed with the Papyrus SDK, so there’s no need to have so many separate doc plug-ins. IMO, all of the Papyrus User Guide documentation should be in one plug-in (org.eclipse.papyrus.doc installed with Papyrus main features) and the Developer Guide documentation in another plug-in (org.eclipse.papyrus.doc.isv installed with the SDK feature). This is, in fact, the pattern established by many Eclipse projects and probably an “officially” recommended guideline.
Cheers,
Christian
Hi Christian, I think that the structure of the repository should be design to help developers/committers : ð As Onder said : it’s easier for a newcomer (even for experienced developer) to find and keep up to date documentation if it’s on the same place as the code. About help.eclipse.org, we should write a little mojo for tycho and have a specific packaging grouping all documentation in one plugin (I believe it’s what is required by the admins : “the name of your help plugin and where we can find it on download.eclipse.org”) ð As François said : packaging goal shouldn’t have any impacts on our plugin/directory structure Happy New Year, Benoit 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 ?
|
