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]
