RE: FOP Release Automation

[Robert Meyer]

Hi All,

This is an update into my investigations on automating the release process for 
FOP. As we're nearing release it looks as though version 2.0 will remain a 
manual process for the time being. That's not to say that it will forever 
remain like that but at present unless a breakthrough occurs or I receive some 
feedback from the infrastructure team, I don't currently have the necessary 
knowledge on the Apache infrastructure (or Perl know how) to achieve the 
desired result despite my efforts.

During the time since my last message I found a solution using a markdown 
extension. This appeared to fulfil all of our requirements and after writing 
and testing one, it seemed to simply be a case of installing it. Due to the 
nature of Apache's websites this was not something I could do myself as we 
don't have control over the CMS. After raising a ticket with the infrastructure 
team about doing this, I was pointed to another project called Thrift. Their 
site appeared to provide tag replacement using preexisting functionality found 
in the perl modules of the Apache CMS.

After reading the documentation and experimenting I've reached somewhat of an 
impasse due to a number of reasons. Firstly the documentation on customizing 
these patterns is limited and covers only basic patterns. Second, my own 
experience with Perl is lacking and as such makes it hard to debug and 
understand some of the more complicated required modules and sections of the 
CMS. Finally during my testing the errors I was getting were extremely 
unhelpful and provide next to no clues as to where the problem lay in my own 
code. Instead they point to the Perl CMS libraries highlighting missing 
expected characters and at a guess incompatibilities between the markdown we're 
using and what's expected by the pattern's own subroutine.

I have tried to follow and utilize the code found in the Thrift project with 
little luck. I have posted on the infrastructure mailing list for help but as 
of yet have not had any responses. I am guessing this is not a commonly used 
feature and as such knowledge on the subject may be in short supply. As such 
and without possibility of using the markdown extension we're left with the 
manual process for the time being. I will keep an eye out on the infrastructure 
page and prod them occasionally to see if I can move things along.

Apologies for the long e-mail but just wanted to keep you all updated.

Robert Meyer

> Date: Mon, 2 Jun 2014 14:44:58 +0100
> From: bowditch_ch...@hotmail.com
> To: fop-dev@xmlgraphics.apache.org
> Subject: 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  > > 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 c

[jira] [Created] (FOP-2394) [PATCH] Remove non-standard layout extensions

[Vincent Hennebert (JIRA)]

Vincent Hennebert created FOP-2394:
--

 Summary: [PATCH] Remove non-standard layout extensions
 Key: FOP-2394
 URL: https://issues.apache.org/jira/browse/FOP-2394
 Project: Fop
  Issue Type: Improvement
  Components: layout/unqualified
Reporter: Vincent Hennebert


This patch removes support for the 'distribute' and 'fill' extension values for 
the display-align property, and the fox:block-progression-unit extension 
property.

Those extensions have never been publicized, are not working, are untested and 
get in the way every time some refactoring is done on the layout engine. 
Removing them allows to remove quite a bit of code.

If nobody objects within the next few days, I'll apply the patch to trunk.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FOP-2394) [PATCH] Remove non-standard layout extensions

[Vincent Hennebert (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FOP-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vincent Hennebert updated FOP-2394:
---

Attachment: remove-non-standard-layout-extensions.patch

> [PATCH] Remove non-standard layout extensions
> -
>
> Key: FOP-2394
> URL: https://issues.apache.org/jira/browse/FOP-2394
> Project: Fop
>  Issue Type: Improvement
>  Components: layout/unqualified
>Reporter: Vincent Hennebert
> Attachments: remove-non-standard-layout-extensions.patch
>
>
> This patch removes support for the 'distribute' and 'fill' extension values 
> for the display-align property, and the fox:block-progression-unit extension 
> property.
> Those extensions have never been publicized, are not working, are untested 
> and get in the way every time some refactoring is done on the layout engine. 
> Removing them allows to remove quite a bit of code.
> If nobody objects within the next few days, I'll apply the patch to trunk.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FOP-2280) Retrieved marker content ignores writing-mode

[Matthias Reischenbacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FOP-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthias Reischenbacher updated FOP-2280:
-

Attachment: 2280_hebrew_marker.patch

> Retrieved marker content ignores writing-mode
> -
>
> Key: FOP-2280
> URL: https://issues.apache.org/jira/browse/FOP-2280
> Project: Fop
>  Issue Type: Bug
>  Components: layout/unqualified
>Reporter: Matthias Reischenbacher
> Attachments: 2280_hebrew_marker.patch, hebrew_marker.fo, 
> hebrew_marker.pdf
>
>
> Retrieve-marker inside static content ignores current writing-mode. See 
> sample fo file and current PDF output.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FOP-2280) [PATCH] Retrieved marker content ignores writing-mode

[Matthias Reischenbacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FOP-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthias Reischenbacher updated FOP-2280:
-

Summary: [PATCH] Retrieved marker content ignores writing-mode  (was: 
Retrieved marker content ignores writing-mode)

> [PATCH] Retrieved marker content ignores writing-mode
> -
>
> Key: FOP-2280
> URL: https://issues.apache.org/jira/browse/FOP-2280
> Project: Fop
>  Issue Type: Bug
>  Components: layout/unqualified
>Reporter: Matthias Reischenbacher
> Attachments: 2280_hebrew_marker.patch, hebrew_marker.fo, 
> hebrew_marker.pdf
>
>
> Retrieve-marker inside static content ignores current writing-mode. See 
> sample fo file and current PDF output.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: FOP Release Automation

[Glenn Adams]

I will -1 any proposal that involves using Perl.


On Tue, Jul 15, 2014 at 3:35 AM, Robert Meyer  wrote:

> Hi All,
>
> This is an update into my investigations on automating the release process
> for FOP. As we're nearing release it looks as though version 2.0 will
> remain a manual process for the time being. That's not to say that it will
> forever remain like that but at present unless a breakthrough occurs or I
> receive some feedback from the infrastructure team, I don't currently have
> the necessary knowledge on the Apache infrastructure (or Perl know how) to
> achieve the desired result despite my efforts.
>
> During the time since my last message I found a solution using a markdown
> extension. This appeared to fulfil all of our requirements and after
> writing and testing one, it seemed to simply be a case of installing it.
> Due to the nature of Apache's websites this was not something I could do
> myself as we don't have control over the CMS. After raising a ticket with
> the infrastructure team about doing this, I was pointed to another project
> called Thrift. Their site appeared to provide tag replacement using
> preexisting functionality found in the perl modules of the Apache CMS.
>
> After reading the documentation and experimenting I've reached somewhat of
> an impasse due to a number of reasons. Firstly the documentation on
> customizing these patterns is limited and covers only basic patterns.
> Second, my own experience with Perl is lacking and as such makes it hard to
> debug and understand some of the more complicated required modules and
> sections of the CMS. Finally during my testing the errors I was getting
> were extremely unhelpful and provide next to no clues as to where the
> problem lay in my own code. Instead they point to the Perl CMS libraries
> highlighting missing expected characters and at a guess incompatibilities
> between the markdown we're using and what's expected by the pattern's own
> subroutine.
>
> I have tried to follow and utilize the code found in the Thrift project
> with little luck. I have posted on the infrastructure mailing list for help
> but as of yet have not had any responses. I am guessing this is not a
> commonly used feature and as such knowledge on the subject may be in short
> supply. As such and without possibility of using the markdown extension
> we're left with the manual process for the time being. I will keep an eye
> out on the infrastructure page and prod them occasionally to see if I can
> move things along.
>
> Apologies for the long e-mail but just wanted to keep you all updated.
>
> Robert Meyer
>
> > Date: Mon, 2 Jun 2014 14:44:58 +0100
> > From: bowditch_ch...@hotmail.com
> > To: fop-dev@xmlgraphics.apache.org
> > Subject: 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  > > > 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
> > >> 
> > >> Subje

Re: FOP Release Automation

[Clay Leeds]

Considering ASF-CMS is written in Perl, I wouldn't discount Perl out-of-hand. 
However, IMFO (sorry! Typo, but I could t bring myself to change it! ;-) I 
would think a solution blessed by infra@ would be acceptable, especially if 
they'll bless and/or maintain it!
Cheers!

Clay

--

"My religion is simple. My religion is kindness."
- HH The Dalai Lama of Tibet

> On Jul 15, 2014, at 7:01 AM, Glenn Adams  wrote:
> 
> I will -1 any proposal that involves using Perl.
> 
> 
>> On Tue, Jul 15, 2014 at 3:35 AM, Robert Meyer  wrote:
>> Hi All,
>> 
>> This is an update into my investigations on automating the release process 
>> for FOP. As we're nearing release it looks as though version 2.0 will remain 
>> a manual process for the time being. That's not to say that it will forever 
>> remain like that but at present unless a breakthrough occurs or I receive 
>> some feedback from the infrastructure team, I don't currently have the 
>> necessary knowledge on the Apache infrastructure (or Perl know how) to 
>> achieve the desired result despite my efforts.
>> 
>> During the time since my last message I found a solution using a markdown 
>> extension. This appeared to fulfil all of our requirements and after writing 
>> and testing one, it seemed to simply be a case of installing it. Due to the 
>> nature of Apache's websites this was not something I could do myself as we 
>> don't have control over the CMS. After raising a ticket with the 
>> infrastructure team about doing this, I was pointed to another project 
>> called Thrift. Their site appeared to provide tag replacement using 
>> preexisting functionality found in the perl modules of the Apache CMS.
>> 
>> After reading the documentation and experimenting I've reached somewhat of 
>> an impasse due to a number of reasons. Firstly the documentation on 
>> customizing these patterns is limited and covers only basic patterns. 
>> Second, my own experience with Perl is lacking and as such makes it hard to 
>> debug and understand some of the more complicated required modules and 
>> sections of the CMS. Finally during my testing the errors I was getting were 
>> extremely unhelpful and provide next to no clues as to where the problem lay 
>> in my own code. Instead they point to the Perl CMS libraries highlighting 
>> missing expected characters and at a guess incompatibilities between the 
>> markdown we're using and what's expected by the pattern's own subroutine.
>> 
>> I have tried to follow and utilize the code found in the Thrift project with 
>> little luck. I have posted on the infrastructure mailing list for help but 
>> as of yet have not had any responses. I am guessing this is not a commonly 
>> used feature and as such knowledge on the subject may be in short supply. As 
>> such and without possibility of using the markdown extension we're left with 
>> the manual process for the time being. I will keep an eye out on the 
>> infrastructure page and prod them occasionally to see if I can move things 
>> along.
>> 
>> Apologies for the long e-mail but just wanted to keep you all updated.
>> 
>> Robert Meyer
>> 
>> > Date: Mon, 2 Jun 2014 14:44:58 +0100
>> > From: bowditch_ch...@hotmail.com
>> > To: fop-dev@xmlgraphics.apache.org
>> > Subject: 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 > > > > wrote:
>> > >> Hi,
>> > >>
>> > >> I like the simplicity of your idea, but the web interface is not so 
>> > >> easy to dismiss unfortunately.
>> > >>
>> > >

Re: FOP Release Automation

[Glenn Adams]

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.


On Tue, Jul 15, 2014 at 8:30 AM, Clay Leeds 
wrote:

> Considering ASF-CMS is written in Perl, I wouldn't discount Perl
> out-of-hand. However, IMFO (sorry! Typo, but I could t bring myself to
> change it! ;-) I would think a solution blessed by infra@ would be
> acceptable, especially if they'll bless and/or maintain it!
>
> Cheers!
>
> Clay
>
> --
>
> "My religion is simple. My religion is kindness."
> - HH The Dalai Lama of Tibet
>
>
> On Jul 15, 2014, at 7:01 AM, Glenn Adams  wrote:
>
> I will -1 any proposal that involves using Perl.
>
>
> On Tue, Jul 15, 2014 at 3:35 AM, Robert Meyer 
> wrote:
>
>> Hi All,
>>
>> This is an update into my investigations on automating the release
>> process for FOP. As we're nearing release it looks as though version 2.0
>> will remain a manual process for the time being. That's not to say that it
>> will forever remain like that but at present unless a breakthrough occurs
>> or I receive some feedback from the infrastructure team, I don't currently
>> have the necessary knowledge on the Apache infrastructure (or Perl know
>> how) to achieve the desired result despite my efforts.
>>
>> During the time since my last message I found a solution using a markdown
>> extension. This appeared to fulfil all of our requirements and after
>> writing and testing one, it seemed to simply be a case of installing it.
>> Due to the nature of Apache's websites this was not something I could do
>> myself as we don't have control over the CMS. After raising a ticket with
>> the infrastructure team about doing this, I was pointed to another project
>> called Thrift. Their site appeared to provide tag replacement using
>> preexisting functionality found in the perl modules of the Apache CMS.
>>
>> After reading the documentation and experimenting I've reached somewhat
>> of an impasse due to a number of reasons. Firstly the documentation on
>> customizing these patterns is limited and covers only basic patterns.
>> Second, my own experience with Perl is lacking and as such makes it hard to
>> debug and understand some of the more complicated required modules and
>> sections of the CMS. Finally during my testing the errors I was getting
>> were extremely unhelpful and provide next to no clues as to where the
>> problem lay in my own code. Instead they point to the Perl CMS libraries
>> highlighting missing expected characters and at a guess incompatibilities
>> between the markdown we're using and what's expected by the pattern's own
>> subroutine.
>>
>> I have tried to follow and utilize the code found in the Thrift project
>> with little luck. I have posted on the infrastructure mailing list for help
>> but as of yet have not had any responses. I am guessing this is not a
>> commonly used feature and as such knowledge on the subject may be in short
>> supply. As such and without possibility of using the markdown extension
>> we're left with the manual process for the time being. I will keep an eye
>> out on the infrastructure page and prod them occasionally to see if I can
>> move things along.
>>
>> Apologies for the long e-mail but just wanted to keep you all updated.
>>
>> Robert Meyer
>>
>> > Date: Mon, 2 Jun 2014 14:44:58 +0100
>> > From: bowditch_ch...@hotmail.com
>> > To: fop-dev@xmlgraphics.apache.org
>> > Subject: 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 extensibi

Re: FOP Release Automation

[Clay Leeds]

On Jul 15, 2014, at 7:46 AM, Glenn Adams  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

[Glenn Adams]

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 
wrote:

> On Jul 15, 2014, at 7:46 AM, Glenn Adams  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

[Robert Meyer]

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