2012/5/11 Ioan Eugen Stan <[email protected]>: >> My concerns: >> - Have uniform skin between cms and mvn generated pages. >> - Have on all pages the left menu which has 3 parts: the suproject links, >> the reports links and the top james links (about, download, asf). >> - Have on all pages the same top menu with the list of projects. > > We currently don't have any of these. The layout changes when you move > from project to project because each project has it's own site that it > inherits. There is no common parent for all projects.
I don't get this. All of james website and products use the same layout and the same top-menu. Sometimes you will get "older" versions because we never updated some product (so maybe latest changes to the skin have not yet inherited by older projects). But, overall, the skin is the same across the whole website (excluding javadocs and xrefs). > The top menu is also different from project to project: different > ordering and different sizes in CSS and even missing elements. For > example http://james.apache.org/jspf/index.html is missing home, > mailbox, project. Just click on all top menu entries and you will see > for yourself. > > A solution for this is to move the mvn site templates to svn:externals > (to skin project maybe) and import them in every project. This way we > might solve the uniformity issue. A solution is to update the maven generated websites. Either way you are replying to the objection that the whole shouldn't be different saying that currently we have minor differences like one menu voice or different css padding: doesn't sound fair. To fix the difference we would just need to update the parent pom to every product "trunk" and deploy the website for each of them: I did that a couple of years ago, but I had no time since then to update (to be fair this should have been done/scheduled by the people that updated the skin). So the FIX to this issue is to update each product and not to put one more skin in the mix ;-) As I told previously I predict CMS will not replace all of our website docs and we will still generate some of them using maven, so you will have to regenerate maven projects anyway, whatever you do with CMS. One way to improve this would be to create a meta-skin for maven that will output pages without the common parts and then have CMS use the maven output as input and add the common parts before publishing: this will create a double commit on each page changes (and maybe more complex workflow), not sure it worth it, but I'm not against a similar solution. > Indeed, very confusing and my opinion is that having the sidebar > change that much with every project is creating even more confusion. > We should strive for uniform pages but I don't know what support > maven site has for template inheritance, so it might not be possible. > I will look into it. Here is the maven skin: https://svn.apache.org/repos/asf/james/skin/trunk/src/main/resources/META-INF/maven/site.vm and here the common resources used by the skin: https://svn.apache.org/repos/asf/james/skin/trunk/src/main/resources/ Here is the structure defined by our "parent project": https://svn.apache.org/repos/asf/james/project/trunk/src/site/site.xml And here is a definition for a single project: https://svn.apache.org/repos/asf/james/mime4j/trunk/src/site/site.xml The different outputs are a consequence of products referencing an older parent project (that have a different layout). > @Stefano: We might not loose browser editing. I'm not sure but I think > the bookmarklet will resolve the source that generated the page even > if it's not markdown formatted, by looking at which reg-exp from > path.pm it matches. OK, good. How is permission to the editing handled? Does it ask for svn credentials or what else? My question is about who can edit the pages: if we plan to move the wiki content then we should have a way to let non-james-committers to write changes. We don't want anonymous, but will we be able to let every asf member to submit doc changes? Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
