On 30/07/11 13:24, Stefano Bagnara wrote:
2011/7/30 Eric Charles<e...@apache.org>:
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.
mvn site-deploy is good to me.
Will you remove the www svn folder?
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.
I'm also fine having the reports on the website.
How did you define it on jDKIM level ?
Do we still need the site-reports profile in [1] ?
Should we have this behaviour defined in [1] ?
[1] https://svn.apache.org/repos/asf/james/project/trunk/project/pom.xml
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).
OK
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).
I faced same perm issue, and the workaround I applied was to copy to a
tmp folder, going to the server, and make a local copy.
I will start another thread about site deploy.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
--
Eric Charles
http://about.echarles.net
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
