Keiron and Nicola Ken (and anyone else who is interested):

I have the process of building the fop web site mostly scripted at
/home/vmote/script/build-fop-website.bsh. I have a couple of
problems/questions, which I will interject into the src/documentation/README
doc contents below:

> The current procedure is:
>
> - checkout xml-forrest module
> - run: build.sh(bat) dist
> - follow instructions to set FORREST_HOME and path
> - go to xml-fop directory
> - run forrest(.bat)
>
> The documents will then be placed in build/site/

I have been running this on the Apache machine. Is that OK? If successful,
we can theoretically just add a cron job to publish periodically if we wish,
until Forrest is ready to do its magic for us.

When running forrest, I am getting the NoClassDefFoundError on
java.awt.Rectangle, which I assume is Batik failing during pdf generation
because of running in a headless environment. I did not find any of our
solutions in our headless FAQ available on that machine. How have you been
handling this? Or have you been running locally & then uploading the
completed web site?

> NOTE: the compliance.html currently does not work, it can be fixed by
> adding the dtd ref to: build/tmp/context/resources/schema/catalog
> and placing the dtd in: build/tmp/context/resources/schema/dtd/

I'll work on this after I get the basics going.

> To update website
> - put the generated docs into the xml-site module targets/fop/
>   this could be done by simlinking the destination to the targets/fop
> - commit the documents

I wonder if we still should have this under cvs control. It probably doesn't
matter much for the html files, but the pdf files are binary, and cvs is
basically keeping a full copy of each revision. For example, status.pdf is
currently 8328 bytes, and status.pdf,v which contains 3 versions, is 27,769
bytes. Since these are generated files now, we probably don't need an audit
trail of them.

Does committing the documents actually trigger something that immediately
updates the web site, or is there some process that runs periodically that
does that? I am hoping, if this script works, that we can change our
workflow as follows: If a reasonably good question comes up on the user list
that can/should be addressed in our doc, the monitor (usually Joerg or Oleg)
can change the doc, republish the web site, and post an answer that contains
a link to the new doc, along with a comment that it was just updated. In
this way, not only does the question get answered, but the doc is improved,
for little more than the cost of answering it. This only works well if the
doc can be republished almost at will. I'm hoping that the monitors would
view this as an investment that should result in less questions on the user
list (especially after our doc gets a reputation for being thorough), but,
if not, I'll try to cull through the lists to update the doc myself. This
would require a less-frequent update cycle -- once a day is probably plenty.

Victor Mote


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to