Thanks to all your answers. In cactus, I have a depoloy-site target that
takes a "-Dusername=username_on_dadedalus" attribute and which does the
following :
* generates the web site (HTML) and gzip it,
* scp the gzip to the htdocs directory for Cactus
* ssh and execute a ungzip, untar and remove
It is really nice and I can update the Cactus web site in less than 1 minute
...
Any problem with this ? Do we have to conform to other ways of doing it or
we stay like this for the Cactus project ?
Thanks
-Vincent
Here is the script :
--------
<target name="deploy-site" depends="clean,site" if="username">
<property name="homepage"
value="/www/jakarta.apache.org/commons/cactus"/>
<exec dir="." executable="scp">
<arg value="${final.site.name}-${DSTAMP}.tar.gz"/>
<arg value="${username}@jakarta.apache.org:${homepage}"/>
</exec>
<exec dir="." executable="ssh">
<arg line="-l ${username} jakarta.apache.org 'cd
${homepage};gunzip ${site.name}-${DSTAMP}.tar.gz;tar xvf
${site.name}-${DSTAMP}.tar;rm ${site.name}-${DSTAMP}.tar'"/>
</exec>
</target>
--------
----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, August 18, 2001 8:09 PM
Subject: RE: cvs commit: JavaDocs
>
>
> On Sat, 18 Aug 2001, Sanders wrote:
>
> > Vincent,
> >
> > As far as I know the html is checked in so that it can be checked out
> > onto the jakarta site. So the developer sets up his/her machine, and
> > then generates and checks in docs, and then logs onto the website box
> > and does a 'cvs update', which just pulls out the html.
> >
> > Scott Sanders
> >
>
> That's the reason Jon set up jakarta-site2 this way, and whoever set up
> the original website for Commons copied it. I don't like it either, but
> haven't had time to define an alternative approach.
>
> Off the top of my head, there would seem to be two options:
>
> * Require developers who want to update the web site to configure
> their environment on daedalus so that they can check out the
> xdocs and actually run the transformations in place. (Historical
> note - originally, the machine which ran the web sites did not have
> a Java2 environment available, so we couldn't have done this even
> if we wanted to. That is no longer the case.)
>
> * Require developers who want to update the web site to run
> the transformations on their own systems, and then propogate
> the generated files up to the server somehow. (For Struts, I
> do this by scp'ing the struts-documentation.war file up to the
> server, then logging on and unpacking it.
>
> The latter alternative would be preferable IMHO, but *only* if we can
> automate the "propogate and expand" part, perhaps with an Ant task that
> does all the necessary work.
>
> Craig
>
>
