Hello again, I've moved to maven site building. See https://issues.apache.org/jira/browse/JAMES-1374?focusedCommentId=13276653#comment-13276653 for details.
As I see it we are in straight line for complete CMS migration. There are a few things to fix: move all the site xdocs to site-cms and provide svn:externals definition back to the project. After this we will have the old site with a new build system, docs with the project and automatic site building on documentation update commit. Cheers, 2012/5/11 Ioan Eugen Stan <[email protected]>: > 2012/5/11 Stefano Bagnara <[email protected]>: >> 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). > > 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: [email protected] >> For additional commands, e-mail: [email protected] >> > > > > -- > Ioan Eugen Stan > http://ieugen.blogspot.com/ *** http://bucharest-jug.github.com/ *** -- Ioan Eugen Stan http://ieugen.blogspot.com/ *** http://bucharest-jug.github.com/ *** --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
