I just fixed the perms... Bye, Norman
2011/7/30 Stefano Bagnara <[email protected]>: > 2011/7/30 Eric Charles <[email protected]>: >> On 30/07/11 00:42, Stefano Bagnara wrote: >>> >>> I guess it's an year or more I don't deploy james websites and I found >>> I don't know the updated way to do that. >>> >>> I see the svn folder james/sites/trunk/www is outdated so I guess we >>> don't use it anymore (what about removing it?). >>> >> >> It is not used for now, but the goal is to recommit updated sites there, and >> ask Apache Infra to SvnPubSub so we don't have to svn up and wait the sync >> for now. > > It's clear that we don't update that svn folder anymore. Infra doesn't > require anymore us to have the website in svn. > > "mvn site-deploy" is much faster/easier than publishing to a local > folder and committing: expecially when you have to work with > multimodules sites (the staged site is not ok, and you have to > manually copy each module/target/site folder over the right svn > working copy in order to commit the stuff). > > So unless anyone have a better workflow I propose to remove the svn > folder and simply use site-deploy. > >>> How am I supposed to update the web site? >>> >>> I tried site:deploy for the project, but it doesn't deploy the full site >>> "mvn -Psite-reports site" creates the reports, but overwrite the index >>> from the previous command. >>> >>> What are the right steps to deploy updated site and reports? >> >> We talked about the reports some time ago and decided to have two separate >> sites: the end user site and the site with reports. > > I can't see the whole picture: where is deployed the end user site? > where is deployed the site with reports? > >> The goal was not to have the public site with some reports, even if it's >> true that previous mime4j site had such reports. > > So "the goal" is to remove reports from james.apache.org for all of > our product?? I don't like this goal. > > I searched the archives and I don't find too much discussion/agreement > on something similar to this: I found some ideas, some plan, but > nothing like "ok, let's do this way, if anyone is against this speak > now" Have you any link for me to read? > > I just reintroduced the reports for jDKIM as I think xrefs, coverage, > svn instructions and the other reports are really useful to the > developers coming to our site (I use them too). mvn site-deploy worked > fine for jDKIM. > >> I think you could copy some definitions from the site-reports profile to get >> this reports in the public web site. > > I think I found my way changing the main pom for jDKIM by removing > "inheritance" of the "generate reports variable" from the parent pom. > >>> Also, I see the html generated from apt sources for mime4j don't >>> produce anymore valid html (bad links): is this something related to >>> newer maven site plugins? Do you know anything about this before I >>> start digging it? >> >> For server, I remember I migrated the few apt to some xml (just to have a >> uniform format). >> I suppose the issue come from the new maven 3 site plugins. >> No idea how to solve it. Eventually, you can migrate the apt to the xml. > > I found some updated docs for apt. > Links to anchors are now {{{anchor}text}} and not {{{#anchor}text}} > Links to relative urls are now {{{./relative}text}} and not > {{{relative}text}}. > > The generated usage.html is good now (the sematic content was already > up-to-date with 0.7). > > Unfortunately mvn site-deploy for mime4j just failed because many > files inside the mime4j folder on people.apache.org are 644 instead of > 664 so I get permission denied. > > Many of them are "eric.apache" so I guess you (Eric) can fix them. (I > use a script I created some years ago to make sure permissions in www > for files owned by me are correct): > ------ > #!/bin/sh > find /www/james.apache.org ! -perm 775 -type d -user ${USER} -exec > chmod 775 {} \; > find /www/james.apache.org ! -perm 664 -type f -user ${USER} -exec > chmod 664 {} \; > find /www/james.apache.org -name \*\.cgi -type f -exec chmod 775 {} \; > ----- > > The same happens with main project deployment. I've been able to > deploy some of the files by moving the "bad permissioned" files to an > "old" folder, but I can't do this for some of the bad permissioned > folders, like "js" and others (please remove "old" folder while you > fix the permissions, and maybe also remove ".tmp", "tmp"). > > Maybe we should also remove all of the .svn folders from there (as svn > is not updated anymore): they contains files with wrong permissions > owned by many apache devs (eric, norman, rdonking). > > Stefano > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
