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 ;-)



From: simonsteiner1...@gmail.com
To: 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
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:


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:


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.



Reply via email to