Hi All,
I certainly use the web interface when making small tweaks to the docs.
As you know users occasionally report small mistakes that require minor
tweaks. I'd like to streamline the updating of the website for release
purposes but I don't want to disable/prevent the current web
interface which works well when all you want to do is make a minor
adjustment in response to a user e-mail.
Rob is away this week, but he will continue the investigation into
scripting the website updates when he returns.
Thanks for the ideas so far, a few promising leads.
Thanks,
Chris
On 30/05/2014 17:23, Clay Leeds wrote:
Agreed, ‘some’ people wouldn’t be happy with that. ;-)
I wonder if the CMS Web interface could be extended to allow for a few
keywords like FOP_VERSION, FOP_REVISION, FOP_BRANCH, etc.
The CMS tool's WYSIWYG interface indicates it uses the Wysiwym
MarkDown Editor, which is extensible:
https://web.archive.org/web/20110121060932/http://wmd-editor.com/
(site’s down & hasn’t been updated since 2011)...
or
https://code.google.com/p/wmd/
We might still need to do some ANT hanky panky, but at least if we
could leverage WMD’s extensibility it would help us get where we’re
trying to go?
Clay
On May 30, 2014, at 7:19 AM, Robert Meyer <rme...@hotmail.co.uk
<mailto:rme...@hotmail.co.uk>> wrote:
Hi,
I like the simplicity of your idea, but the web interface is not so
easy to dismiss unfortunately.
If you do have a copy with those tags in, if any changes are made on
the web interface then that copy would become out of date.
We could always shutdown the web interface, but I don't think too
many people would be happy with that ;-)
Regards,
Robert
------------------------------------------------------------------------
From: simonsteiner1...@gmail.com <mailto:simonsteiner1...@gmail.com>
To: fop-dev@xmlgraphics.apache.org
<mailto:fop-dev@xmlgraphics.apache.org>
Subject: RE: FOP Release Automation
Date: Fri, 30 May 2014 14:48:15 +0100
Hi,
Simple way is to store docs inside fop repo:
Fop/docs/index.markdown
Inside markdown file you reference ant properties eg:
${version}
Then you call which does ant expandproperties and calls markdown to
html tool:
ant docs
Then you call which does a zip, scp and unzip of html files to web
server:
ant upload-docs
This method doesn’t support web interface of editing files but I
don’t see how this is really needed.
If I submit a patch to fop it should also contain doc changes rather
than having separate repo and patch for that.
Thanks
*From:*Robert Meyer [mailto:rme...@hotmail.co.uk]
*Sent:*30 May 2014 14:05
*To:*fop-dev@xmlgraphics.apache.org
<mailto:fop-dev@xmlgraphics.apache.org>
*Subject:*RE: FOP Release Automation
Hi,
After investigating your suggestions Clay I have found that svn-hooks
can't be used for the purpose we require unfortunately as it may lead
to problems with how SVN operates and also may have some unexpected
results with files being committed. This is stated in the
documentation under "Creating Repository Hooks" highlighted in the
warning red box further down:
http://www-inst.eecs.berkeley.edu/~cs61b/fa09/docs/svn-book-html-chunk/svn.reposadmin.create.html
<http://www-inst.eecs.berkeley.edu/%7Ecs61b/fa09/docs/svn-book-html-chunk/svn.reposadmin.create.html>
Pascal, I agree that the process is fairly straightforward, but I
have been asked to automate this further so am just looking into
ideas presently.
I think a possible way forward then would be to use your suggestion
Pascal of placing the versioned docs for the site inside the FOP
repository for their associated version. These can then be referenced
using the svn-externals from the main site repository.
In addition to this, the main site files (which would need to be
updated) could contain tags for the last three versions which would
be replaced using Clay's markdown pre-processor suggestion. The
pre-processor would replace the tags with values stored in a
properties file in the main site repository.
To create a release, the user would need to update the svn-external
references to account for the new version and update the properties
file for tag replacement. When the properties file is pushed it will
be read by the custom markdown pre-processor and display the new
version when rendered.
Those two stages could be done using a single script to simplify
things further, but the main complication is getting the markdown
pre-processor working. From looking at this page:
http://www.apache.org/dev/cmsref.html#markdown
I am guessing we use PyPy (Python Markdown) which supports
extensions, so I will look at this shortly to try out a small example
and investigate the feasibility of doing this. There is also the
matter of updating the versioned documents for each FOP when a new
version is released, but maybe this could be done with the
pre-processor as well.
Anyway, let me know what you think.
Regards,
Robert