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 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
Re: FOP Release Automation
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 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
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:
http://www-inst.eecs.berkeley.edu/~cs61b/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
RE: FOP Release Automation
I'll definitely look into those. I'm going to be away on holiday now for a week
or so but will continue once I get back.
Many thanks!
Robert
From: Clay Leedsmailto:the.webmaes...@gmail.com
Sent: 5/30/2014 17:24
To: Apache FOPmailto:fop-dev@xmlgraphics.apache.org
Subject: Re: FOP Release Automation
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 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
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:
http://www-inst.eecs.berkeley.edu/~cs61b/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
