2012/5/11 Stefano Bagnara <apa...@bago.org>: > 2012/5/11 Ioan Eugen Stan <stan.ieu...@gmail.com>: >>> 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).
Sorry, my mistake. I noticed the update date in the upper right a bit late. >> 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. Yes, we should update them more often. CMS will hopefully enable automatic update on change. About the difference in CSS: I'm just saying that it's sloppy and a very unprofessional look that we promote. > 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. After following all the discussions and the requirements put on so far I've came to the conclusion that it's best to keep the site building as is and use maven. This was mentioned on the jira issue but the documentation is very scarce. I'm looking over to http://maventest.apache.org. See Maven at the end of www.apache.org/dev/cmsadoption.html . Source is here http://svn.apache.org/repos/asf/maven/site/branches/INFRA-4466/trunk/ . Let's hope it supports externals so we can keep our docs where they are. If not, we might be required to do some merging of sources from one tree to another just to keep the docs with the sources and have a uniform site. >> 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. I got that finally :). Thanks. > 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? Well, there is authoring and publish. Authoring trigger builds that go into an online staging area. (http://james.staging.apache.org for us) Publishing moves them to production (james.apache.org). More people should be allowed to author because the changes need to get published to get to production/live. So it should be supported but I don't know many details. We'll find out more along the way. > Stefano > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > -- Ioan Eugen Stan http://ieugen.blogspot.com/ *** http://bucharest-jug.github.com/ *** --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
