Re: FOP Release
On Wed, Apr 22, 2015 at 9:40 AM, Chris Bowditch bowditch_ch...@hotmail.com wrote: I agree, but as Simon pointed out PDFBox is not a dependency of FOP, but of PDF plug-in, which is a separate project with a separate release cycle. The PDF plug-in project is an optional dependency of FOP, not required for core functionality. So the proposal is just to release the FOP project, not PDF plug-in. This means anyone wishing to use PDF-plugin with the new release of FOP would need to build it from source code using a PDFBox snaphot. Not ideal, but we are long overdue a FOP release, and only a small number of users are using the PDF plug-in. So I'm +1 to this proposal. ok; that works for me... on another point, when can we transition to maven? our ant configurations are difficult to maintain and understand; we should modernize Thanks, Chris On 22/04/2015 14:28, Glenn Adams wrote: I'm not comfortable requiring use of a snapshot dependency. For example, that would prevent deployment to maven central. On Wed, Apr 22, 2015 at 1:18 AM, Chris Bowditch bowditch_ch...@hotmail.com mailto:bowditch_ch...@hotmail.com wrote: Hi Glen, Its expected that a -1 vote includes a justification. You may well be right, but we are not mind readers and have no idea what you are thinking... Thanks, Chris On 21/04/2015 16:32, Glenn Adams wrote: -1 On Tue, Apr 21, 2015 at 9:21 AM, Simon Steiner simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com wrote: Hi, Since Batik and XGC have been released, are we ready to release FOP? It has been said we can’t release PDF plugin using a snapshot release of PDFBox 2.0. PDFBox 1.8 is missing font parsing libraries we need for font merging. We could make release a PDF plugin beta release using snapshot of PDFBox or ask user to use PDF plugin snapshot version with FOP 2.0. Thanks
Re: FOP Release
I think that maven will be embraced as soon as there is a volunteer to do the transition. On 4/22/15 6:13 PM, Glenn Adams wrote: On Wed, Apr 22, 2015 at 9:40 AM, Chris Bowditch bowditch_ch...@hotmail.com mailto:bowditch_ch...@hotmail.com wrote: I agree, but as Simon pointed out PDFBox is not a dependency of FOP, but of PDF plug-in, which is a separate project with a separate release cycle. The PDF plug-in project is an optional dependency of FOP, not required for core functionality. So the proposal is just to release the FOP project, not PDF plug-in. This means anyone wishing to use PDF-plugin with the new release of FOP would need to build it from source code using a PDFBox snaphot. Not ideal, but we are long overdue a FOP release, and only a small number of users are using the PDF plug-in. So I'm +1 to this proposal. ok; that works for me... on another point, when can we transition to maven? our ant configurations are difficult to maintain and understand; we should modernize Thanks, Chris On 22/04/2015 14:28, Glenn Adams wrote: I'm not comfortable requiring use of a snapshot dependency. For example, that would prevent deployment to maven central. On Wed, Apr 22, 2015 at 1:18 AM, Chris Bowditch bowditch_ch...@hotmail.com mailto:bowditch_ch...@hotmail.com mailto:bowditch_ch...@hotmail.com mailto:bowditch_ch...@hotmail.com wrote: Hi Glen, Its expected that a -1 vote includes a justification. You may well be right, but we are not mind readers and have no idea what you are thinking... Thanks, Chris On 21/04/2015 16:32, Glenn Adams wrote: -1 On Tue, Apr 21, 2015 at 9:21 AM, Simon Steiner simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com wrote: Hi, Since Batik and XGC have been released, are we ready to release FOP? It has been said we can’t release PDF plugin using a snapshot release of PDFBox 2.0. PDFBox 1.8 is missing font parsing libraries we need for font merging. We could make release a PDF plugin beta release using snapshot of PDFBox or ask user to use PDF plugin snapshot version with FOP 2.0. Thanks
Re: FOP Release
I agree, but as Simon pointed out PDFBox is not a dependency of FOP, but of PDF plug-in, which is a separate project with a separate release cycle. The PDF plug-in project is an optional dependency of FOP, not required for core functionality. So the proposal is just to release the FOP project, not PDF plug-in. This means anyone wishing to use PDF-plugin with the new release of FOP would need to build it from source code using a PDFBox snaphot. Not ideal, but we are long overdue a FOP release, and only a small number of users are using the PDF plug-in. So I'm +1 to this proposal. Thanks, Chris On 22/04/2015 14:28, Glenn Adams wrote: I'm not comfortable requiring use of a snapshot dependency. For example, that would prevent deployment to maven central. On Wed, Apr 22, 2015 at 1:18 AM, Chris Bowditch bowditch_ch...@hotmail.com mailto:bowditch_ch...@hotmail.com wrote: Hi Glen, Its expected that a -1 vote includes a justification. You may well be right, but we are not mind readers and have no idea what you are thinking... Thanks, Chris On 21/04/2015 16:32, Glenn Adams wrote: -1 On Tue, Apr 21, 2015 at 9:21 AM, Simon Steiner simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com wrote: Hi, Since Batik and XGC have been released, are we ready to release FOP? It has been said we can’t release PDF plugin using a snapshot release of PDFBox 2.0. PDFBox 1.8 is missing font parsing libraries we need for font merging. We could make release a PDF plugin beta release using snapshot of PDFBox or ask user to use PDF plugin snapshot version with FOP 2.0. Thanks
Re: FOP Release
Hi Glen, Its expected that a -1 vote includes a justification. You may well be right, but we are not mind readers and have no idea what you are thinking... Thanks, Chris On 21/04/2015 16:32, Glenn Adams wrote: -1 On Tue, Apr 21, 2015 at 9:21 AM, Simon Steiner simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com wrote: Hi, Since Batik and XGC have been released, are we ready to release FOP? It has been said we can’t release PDF plugin using a snapshot release of PDFBox 2.0. PDFBox 1.8 is missing font parsing libraries we need for font merging. We could make release a PDF plugin beta release using snapshot of PDFBox or ask user to use PDF plugin snapshot version with FOP 2.0. Thanks
Re: FOP Release
When I suggested releasing Batik back in December, Glenn mentioned that he wanted to fix some issues (namely https://issues.apache.org/jira/browse/FOP-2391) before releasing FOP 2.0. I assume this is the reason for -1, but I agree that a justification would help since not everyone may remember what was discussed in December. On 4/22/15 9:18 AM, Chris Bowditch wrote: Hi Glen, Its expected that a -1 vote includes a justification. You may well be right, but we are not mind readers and have no idea what you are thinking... Thanks, Chris On 21/04/2015 16:32, Glenn Adams wrote: -1 On Tue, Apr 21, 2015 at 9:21 AM, Simon Steiner simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com wrote: Hi, Since Batik and XGC have been released, are we ready to release FOP? It has been said we can’t release PDF plugin using a snapshot release of PDFBox 2.0. PDFBox 1.8 is missing font parsing libraries we need for font merging. We could make release a PDF plugin beta release using snapshot of PDFBox or ask user to use PDF plugin snapshot version with FOP 2.0. Thanks
Re: FOP Release
-1 On Tue, Apr 21, 2015 at 9:21 AM, Simon Steiner simonsteiner1...@gmail.com wrote: Hi, Since Batik and XGC have been released, are we ready to release FOP? It has been said we can’t release PDF plugin using a snapshot release of PDFBox 2.0. PDFBox 1.8 is missing font parsing libraries we need for font merging. We could make release a PDF plugin beta release using snapshot of PDFBox or ask user to use PDF plugin snapshot version with FOP 2.0. Thanks
RE: FOP Release
Hi, Its listed here https://xmlgraphics.apache.org/fop/trunk/running.html Thanks From: Clay Leeds [mailto:the.webmaes...@gmail.com] Sent: 21 April 2015 21:23 To: Apache FOP Subject: Re: FOP Release One of the changes for PDFBox 2.0.0 (from what I gather from the PDFBox ‘Ideas’ page), is a switch to Java 1.6. We discussed a switch for FOP that required a higher version of Java (I believe it was 1.6, but don’t recall). But I can’t find anywhere on our site that indicates what the minimum Java requirement actually is. I’d like to update the site to include the minimum requirements if someone can let me know what those are… ;-) Clay On Apr 21, 2015, at 8:21 AM, Simon Steiner simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com wrote: Hi, Since Batik and XGC have been released, are we ready to release FOP? It has been said we can’t release PDF plugin using a snapshot release of PDFBox 2.0. PDFBox 1.8 is missing font parsing libraries we need for font merging. We could make release a PDF plugin beta release using snapshot of PDFBox or ask user to use PDF plugin snapshot version with FOP 2.0. Thanks
Re: FOP Release
One of the changes for PDFBox 2.0.0 (from what I gather from the PDFBox ‘Ideas’ page), is a switch to Java 1.6. We discussed a switch for FOP that required a higher version of Java (I believe it was 1.6, but don’t recall). But I can’t find anywhere on our site that indicates what the minimum Java requirement actually is. I’d like to update the site to include the minimum requirements if someone can let me know what those are… ;-) Clay On Apr 21, 2015, at 8:21 AM, Simon Steiner simonsteiner1...@gmail.com wrote: Hi, Since Batik and XGC have been released, are we ready to release FOP? It has been said we can’t release PDF plugin using a snapshot release of PDFBox 2.0. PDFBox 1.8 is missing font parsing libraries we need for font merging. We could make release a PDF plugin beta release using snapshot of PDFBox or ask user to use PDF plugin snapshot version with FOP 2.0. Thanks
New FOP Release [was: Re: FOP Release Automation]
Hi, On 15/07/14 16:53, Clay Leeds wrote: On Jul 15, 2014, at 7:46 AM, Glenn Adams gl...@skynav.com wrote: I suppose it depends on whether or not we need to hack perl to use the facility. If there is any alternative that doesn't use perl, then that would be preferable. Frankly, I've never been happy with the new MD based documentation, though Clay has spent an inordinate amount of time tweaking it. Yeah... It's not my favorite either, but at least edits are pretty quick, saved to SVN and we've got a solution to incorporate javadoc, etc. In the meantime, please let me know when we're ready to update the documentation for the Release. It doesn't take me very long to go through the code to make these types of batch edits. snip/ Clay, your offer to help would be greatly appreciated! And since you’re mentioning it, maybe it’s time to think about making a new release of FOP. Although now that the font merging code has been merged to trunk, and introduces a dependency on FontBox 2.0.0, we would have to wait that FontBox 2.0.0 is released first. Or adapt the code to keep the former 1.8.5 dependency (or the newer 1.8.6 released version). In the meantime, can anybody think of features that should definitely be implemented before the release, or bugs fixed? Remember that due to API changes, that release will have to be called 2.0. Thanks, Vincent
RE: New FOP Release [was: Re: FOP Release Automation]
Hi, I switched fop back to fontbox 1.8, so its only the pdfplugin that uses 2.0 and the user would delete 1.8 jar if copying pdfplugin to fop. Thanks -Original Message- From: Vincent Hennebert [mailto:vhenneb...@gmail.com] Sent: 16 July 2014 12:56 To: fop-dev@xmlgraphics.apache.org Subject: New FOP Release [was: Re: FOP Release Automation] Hi, On 15/07/14 16:53, Clay Leeds wrote: On Jul 15, 2014, at 7:46 AM, Glenn Adams gl...@skynav.com wrote: I suppose it depends on whether or not we need to hack perl to use the facility. If there is any alternative that doesn't use perl, then that would be preferable. Frankly, I've never been happy with the new MD based documentation, though Clay has spent an inordinate amount of time tweaking it. Yeah... It's not my favorite either, but at least edits are pretty quick, saved to SVN and we've got a solution to incorporate javadoc, etc. In the meantime, please let me know when we're ready to update the documentation for the Release. It doesn't take me very long to go through the code to make these types of batch edits. snip/ Clay, your offer to help would be greatly appreciated! And since you’re mentioning it, maybe it’s time to think about making a new release of FOP. Although now that the font merging code has been merged to trunk, and introduces a dependency on FontBox 2.0.0, we would have to wait that FontBox 2.0.0 is released first. Or adapt the code to keep the former 1.8.5 dependency (or the newer 1.8.6 released version). In the meantime, can anybody think of features that should definitely be implemented before the release, or bugs fixed? Remember that due to API changes, that release will have to be called 2.0. Thanks, Vincent
Re: FOP Release Automation
I prefer python but bash is fine. OTOH, anything written by Larry Wall should be avoided like the plague. On Tue, Jul 15, 2014 at 8:53 AM, Clay Leeds the.webmaes...@gmail.com wrote: On Jul 15, 2014, at 7:46 AM, Glenn Adams gl...@skynav.com wrote: I suppose it depends on whether or not we need to hack perl to use the facility. If there is any alternative that doesn't use perl, then that would be preferable. Frankly, I've never been happy with the new MD based documentation, though Clay has spent an inordinate amount of time tweaking it. Yeah... It's not my favorite either, but at least edits are pretty quick, saved to SVN and we've got a solution to incorporate javadoc, etc. In the meantime, please let me know when we're ready to update the documentation for the Release. It doesn't take me very long to go through the code to make these types of batch edits. I'm good at this, and who knows, I might even spend the time to write some bash script to help us with the deployment! (you don't have anything against BASH, do ya Glenn?) :-p) (I think that's how to write a smiley with a tongue-in-cheek? :-D)
RE: FOP Release Automation
To use this utility it will require modification of our own Perl modules found on the FOP SVN site. Whether that requires just a change to the patterns (path.pm file) or the more complicated requirement of writing our own pattern subroutine (in the view.pm) I am not yet sure. Unfortunately though I'll have to park this as I currently have no more time I can spend on it but as I said will keep my eye on it and let you know if anything progresses. In the meantime I am guessing there will be a vote to release fairly soon which will result in the documentation needing to be updated. Subject: Re: FOP Release Automation From: the.webmaes...@gmail.com Date: Tue, 15 Jul 2014 07:53:19 -0700 To: fop-dev@xmlgraphics.apache.org On Jul 15, 2014, at 7:46 AM, Glenn Adams gl...@skynav.com wrote: I suppose it depends on whether or not we need to hack perl to use the facility. If there is any alternative that doesn't use perl, then that would be preferable. Frankly, I've never been happy with the new MD based documentation, though Clay has spent an inordinate amount of time tweaking it. Yeah... It's not my favorite either, but at least edits are pretty quick, saved to SVN and we've got a solution to incorporate javadoc, etc. In the meantime, please let me know when we're ready to update the documentation for the Release. It doesn't take me very long to go through the code to make these types of batch edits. I'm good at this, and who knows, I might even spend the time to write some bash script to help us with the deployment! (you don't have anything against BASH, do ya Glenn?) :-p) (I think that's how to write a smiley with a tongue-in-cheek? :-D)
Re: FOP Release Automation
Hi,
If we go to an svn:externals set in CMS repo, pointing to FOP trunk
doc, and 2 last FOP tagged doc, we should take care about having no
change in TAGs. Perhaps a pre-commit hook can do the job here, warning
the committer, or forbidding the commit propagation.
2014-05-30 23:34 GMT+02:00 Robert Meyer rme...@hotmail.co.uk:
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 Leeds
Sent: 5/30/2014 17:24
To: Apache FOP
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
--
pascal
Re: FOP Release Automation
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
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
Re: FOP Release Automation
Hi, I didn't remember that I've rewritten the release page [1] (only refactor, no content change except website update). So, reading it back can figure how simple such task should be. Comments? [1] http://xmlgraphics.apache.org/fop/dev/release.html#cms 2014-05-28 10:57 GMT+02:00 Robert Meyer rme...@hotmail.co.uk: Hi Clay and Pascal, Sorry for my late reply with this. Pascal your idea makes a lot of sense as that will keep all versioned docs with their associated FOP version. I haven't had much of a chance to look at this over the last couple of days but am planning on spending some time in the coming days. Clay, both of what you mention sound intriguing so I'll take a look at those. I think updating it manually will be a last resort as even just writing an ant script would be preferable! If it does come to a script, the idea of copying the trunk folder and doing a find / replace on say trunk and replacing with 2.0 would be an option (with some caveats), but I'll investigate the other methods first. I'll keep you posted. Regards, Robert Meyer Subject: Re: FOP Release Automation From: the.webmaes...@gmail.com Date: Tue, 27 May 2014 21:33:32 -0700 To: fop-dev@xmlgraphics.apache.org Hi, I thought I'd give an update on my research of speeding the RELEASE process... I've spent some time researching, and I've asked for some assistance from site-dev@... Among the ideas I've been researching are: - MarkDown PreProcessor[1] - svn hook I'm not married to either of these solutions, but they look interesting. Of course, another idea, is to do it the OLD way, and I'd be happy to go through and update the MarkDown files with the latest/updated version. MarkDown PreProcessor (a sample I thought was interesting) [1] http://aaronparecki.com/articles/2012/09/01/1/some-enhancements-to-markdown More inline... On May 23, 2014, at 1:00 AM, Pascal Sancho psancho@gmail.com wrote: Hi, The FOP package should not embed the whole website, but only the documentation part, more precisely only the relevant version folder. Currently, FOP doc folder is referenced as svn:externals in FOP repo, resulting on extra irrelevant info, such as other versions, miscellaneous processes, general info, etc. IMHO, FOP versionned doc should be in FOP repo, and Website repo should refer to each FOP versionned doc through svn:externals prop. WDYT? +1 Pascal... Makes sense to me. There's a lot of cruft in there... We'd have to either `svn:externals` a bunch of single files (svn-1.7+), or adjust the site a bit to move the OLD versions somewhere 'out of the way'... (And then add 301 redirects... ;-) Cheers! Clay Leeds @ the.webmaes...@gmail.com My religion is simple. My religion is kindness. HH the Dalai Lama of Tibet -- pascal
Re: FOP Release Automation
Hi, The FOP package should not embed the whole website, but only the documentation part, more precisely only the relevant version folder. Currently, FOP doc folder is referenced as svn:externals in FOP repo, resulting on extra irrelevant info, such as other versions, miscellaneous processes, general info, etc. IMHO, FOP versionned doc should be in FOP repo, and Website repo should refer to each FOP versionned doc through svn:externals prop. WDYT? 2014-05-23 5:15 GMT+02:00 Clay Leeds the.webmaes...@gmail.com: Thank you for looking at this, Robert. I'll take a look at MarkDown solutions as well. Cheers! Clay -- My religion is simple. My religion is kindness. - HH The Dalai Lama of Tibet On May 21, 2014, at 2:24 AM, Robert Meyer rme...@hotmail.co.uk wrote: Hi All, I've been asked to look at a way to automate the FOP release process with regards the website documentation. At the moment every new release requires the following: 1) Download the site from SVN 2) Copy the folder containing the latest version's markdown files (1.1 for example) and rename to the new version 3) Go through all the files manually and update all the references from the old to the new version 4) Update any markdown files in the main directory with regard to the current and previous versions. 5) Delete the oldest version folder as we need only mantain the last 3. 6) Check and resubmit all files back to SVN My initial thought would to have a master copy in a separate directory. That copy would contain a tag in place where the version is given which could be substituted by a script of some kind (ant has a facility to do this). The ant script would also perform all of the above tasks so the only thing left to the user will be to check the output and push the new files. The problem I have with this is that SVN is not the only way in which the files can be edited as there is the web interface. If someone were to edit the files from there, the master copies would become out of date and worse, if someone were to perform a release it would overwrite all those changes. I've been recommended to look at markdown extensions but if anyone else has any ideas on the best way to go about this it would be much appreciated. Thanks, Robert Meyer -- pascal
Re: FOP Release Automation
Thank you for looking at this, Robert. I'll take a look at MarkDown solutions as well. Cheers! Clay -- My religion is simple. My religion is kindness. - HH The Dalai Lama of Tibet On May 21, 2014, at 2:24 AM, Robert Meyer rme...@hotmail.co.uk wrote: Hi All, I've been asked to look at a way to automate the FOP release process with regards the website documentation. At the moment every new release requires the following: 1) Download the site from SVN 2) Copy the folder containing the latest version's markdown files (1.1 for example) and rename to the new version 3) Go through all the files manually and update all the references from the old to the new version 4) Update any markdown files in the main directory with regard to the current and previous versions. 5) Delete the oldest version folder as we need only mantain the last 3. 6) Check and resubmit all files back to SVN My initial thought would to have a master copy in a separate directory. That copy would contain a tag in place where the version is given which could be substituted by a script of some kind (ant has a facility to do this). The ant script would also perform all of the above tasks so the only thing left to the user will be to check the output and push the new files. The problem I have with this is that SVN is not the only way in which the files can be edited as there is the web interface. If someone were to edit the files from there, the master copies would become out of date and worse, if someone were to perform a release it would overwrite all those changes. I've been recommended to look at markdown extensions but if anyone else has any ideas on the best way to go about this it would be much appreciated. Thanks, Robert Meyer
