FYI, here's my current "manual" flow (the mail looks hairy but it boils
down to two shell script calls):
velocity/engine/trunk$ mvn javadoc:javadoc
generates javadocs (aggregated for all modules) into target/site/apidocs
I then run a local script that does:
cd /path/to/velocity
cp -r engine/trunk/target/site/apidocs/*
site/cms/trunk/content/engine/devel/apidocs/
cd site/cms/trunk/content/engine/devel/apidocs/
svn status | egrep "^!" | cut -d' ' -f2- | xargs svn rm
svn status | egrep "^\?" | cut -d' ' -f2- | xargs svn add
From here, I quickly check changes, then I can commit
/content/engine/devel/apidocs/.
If we were using Apache CMS, it would be enough: with a single click you
could ask the CMS to publish the site, first on its staging area, then
on the production site.
But the CMS isn't accepting new sites for now, infra is waiting for a
machine migration and I'm under the impression that it could take a
certain time.
At least, we can use the site generation tools of the CMS locally, and
that's already quite handy.
Here's my "velsite.sh" script for this part (paths have to be adapted)
#!/bin/bash
export MARKDOWN_SOCKET=/tmp/markdown
CMS=~/projects/velocity/apache_cms
VELOCITY=~/projects/velocity
# launch markdown daemon if possible
if [[ `pidof markdownd.py` == "" ]]; then
$CMS/build/markdownd.py
fi
# clears previous output
rm -rf $VELOCITY/site/target
# lanch site generation
$CMS/build/build_site.pl --source-base $VELOCITY/site/cms/trunk
--target-base $VELOCITY/site/target
# copy to production (svnpubsub) directory
echo Copying to production directory...
cp -r $VELOCITY/site/target/content/* $VELOCITY/site/production/
cd $VELOCITY/site/production/
svn status | egrep "^!" | cut -d' ' -f2- | xargs svn rm
svn status | egrep "^\?" | cut -d' ' -f2- | xargs svn add
# then a global svn status on /site/ to inspect changes
cd ..
svn status
In the same script, I also rsync the production directory with my
staging directory, so that I can inspect the result, then commit.
What is a bit ugly, and I totally agree, is that in the process, the
javadocs will traverse four directories... and I'd be happy to let maven
do the work. We could totally bypass the CMS tools, since those files
are just copied as is by the CMS engine. However, the
site/cms/trunk/content/ area seems fine for *archiving* the apidocs for
a specific version.
Claude
On 17/07/2016 17:55, Claude Brisson wrote:
You're most welcome to suggest and implement an alternative. Yes, it
could certainly be automated.
Claude
On 17/07/2016 17:43, Sergiu Dumitriu wrote:
That's ugly, can't Maven put the javadoc in there automatically at build
time, instead of committing in SVN something that's generated?
On 07/16/2016 06:01 PM, [email protected] wrote:
Author: cbrisson
Date: Sat Jul 16 22:01:32 2016
New Revision: 1753002
URL: http://svn.apache.org/viewvc?rev=1753002&view=rev
Log:
[site] update engine/devel javadocs
[This commit notification would consist of 497 parts,
which exceeds the limit of 50 ones, so it was shortened to the
summary.]
---------------------------------------------------------------------
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]
