Re: New FOP Release [was: Re: FOP Release Automation]
Hi Glenn,
The original plan was for Robert Meyer to handle the release. I've moved
him to a different project for a while, so I then decided Vincent should
be our volunteer ;-)
However, it came to light that there is an unwritten policy that
releases can't depend on snapshots of other projects. So that's causing
us a problem for the pdf-plugin and font merging enhancement, which is
one of several key features in this release. The PMC needs to decide if
a snapshot dependency is acceptable or whether we should wait for PDFBox
v2.0 to be released.
Vincent is currently looking additional bugs to fix before the release.
Can we continue this discussion on general@ please, since this affects
all projects, not just FOP
Thanks,
Chris
On 16/07/2014 18:33, Glenn Adams wrote:
On Wed, Jul 16, 2014 at 11:23 AM, Vincent Hennebert
mailto:vhenneb...@gmail.com>> wrote:
On 16/07/14 17:42, Simon Steiner wrote:
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 Simon. That’s great because that means that we can start the
release process of FOP as soon as we are ready.
It would be nice to share the following info:
* who is going to take the lead on performing the release?
* what is a tentative schedule for release, e.g., when should last
changes be integrated?
* what additional integrations (if known) are planned before release?
Vincent
Thanks
-Original Message-
From: Vincent Hennebert [mailto:vhenneb...@gmail.com
<mailto:vhenneb...@gmail.com>]
Sent: 16 July 2014 12:56
To: fop-dev@xmlgraphics.apache.org
<mailto: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 mailto: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.
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]
On Wed, Jul 16, 2014 at 11:23 AM, Vincent Hennebert wrote: > On 16/07/14 17:42, Simon Steiner wrote: > >> 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 Simon. That’s great because that means that we can start the > release process of FOP as soon as we are ready. > It would be nice to share the following info: - who is going to take the lead on performing the release? - what is a tentative schedule for release, e.g., when should last changes be integrated? - what additional integrations (if known) are planned before release? > > Vincent > > > 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 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. >>> >> >> >> 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]
On 16/07/14 17:42, Simon Steiner wrote: 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 Simon. That’s great because that means that we can start the release process of FOP as soon as we are ready. Vincent 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 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. 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 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. 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
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 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. 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
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)
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 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
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
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: >> >
Re: FOP Release Automation
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 Edi
Re: FOP Release Automation
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 > > <mailto:rme...@hotmail.co.uk>> wrote: > > >> Hi, > > >> > > >> I like the simplicity of your idea, but the web interface is not so > >
RE: FOP Release Automation
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 > <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 > >> > >> >
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 <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,
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 :
> 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 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
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<mailto:the.webmaes...@gmail.com>
Sent: 5/30/2014 17:24
To: Apache FOP<mailto: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 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
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 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 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,
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.r
eposadmin.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
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 : > 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 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 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 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 >
Re: FOP Release Automation
in released versions until v1.1, whole website was included in src/documentation, using the old Forrest schema. So, until v1.1, the website repo may embed directly versionned doc. I don't think we need to remove them, just adding or removing a link in sidenav will be sufficient (0.95 doc is always on website). Beginning with fop-next, ie current trunk, we could move trunk doc into fop trunk repos and apply svn:externals in website repo. Attached, I've listed links to versionned doc in CMS FOP -- I like grepwin ;-). Note that for links to latest version, we used variables at the top of MDtext, for easier update during release process. I see no need to redirect anything, just change some values in 5 files. 2014-05-28 6:33 GMT+02:00 Clay Leeds : > 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 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... ;-) -- pascal fop\dev\design\parsing.mdtext ../../trunk/embedding.html ../../trunk/extensions.html fop\dev\extensions.mdtext ../trunk/extensions.html fop\dev\faq.mdtext ../trunk/compiling.html fop\dev\svg.mdtext ../trunk/graphics.html fop\dev\tools.mdtext ../trunk/compiling.html fop\faq.mdtext [currentFop_config_general]: 1.1/configuration.html#general-elements [currentFop_embedding_configExt]: 1.1/embedding.html#config-external [currentFop_embedding_configInt]: 1.1/embedding.html#config-internal [currentFop_embedding_multithreading]: 1.1/embedding.html#multithreading [currentFop_fonts]:1.1/fonts.html [currentFop_graphics]: 1.1/graphics.html [currentFop_graphics_batik]: 1.1/graphics.html#batik [currentFop_graphics_resol]: 1.1/graphics.html#resolution [currentFop_graphics_svgPdfText]: 1.1/graphics.html#svg-pdf-text [currentFop_graphics_svgScaling]: 1.1/graphics.html#svg-scaling [currentFop_hyphenation_support]: 1.1/hyphenation.html#support [currentFop_metadata]: 1.1/metadata.html [currentFop_output_generalFonts]: 1.1/output.html#general-fonts [currentFop_output_pdfFonts]: 1.1/output.html#pdf-fonts [currentFop_output_pdfPostProcess]:1.1/output.html#pdf-postprocess [currentFop_output_pdfWatermark]: 1.1/output.html#pdf-watermark [currentFop_pdfencryption]:1.1/pdfencryption.html [currentFop_running_memory]: 1.1/running.html#memory [currentFop_servlets]: 1.1/servlets.html#servlet [currentFop_servlets_engine]: 1.1/servlets.html#servlet-engine [currentFop_servlets_ie]: 1.1/servlets.html#ie [currentFop_servlets_xslt]:1.1/servlets.html#xslt fop\fo.mdtext [fopLatest_config]: 1.1/configuration.html fop\index.mdtext [fopLatest]: 1.1/ [fopLatest_ouput]: 1.1/output.html fop\maillist.mdtext [fopLatest-runningXalan]: 1.1/running.html#check-input fop\quickstartguide.mdtext [currentFop_compile]: 1.1/compiling.html [currentFop_config]: 1.1/configuration.html [currentFop_running]: 1.1/running.html [currentFop_embedding]: 1.1/embedding.html [currentFop_servlets]: 1.1/servlets.html [currentFop_anttask]: 1.1/anttask.html [currentFop_index]: 1.1/index.html
Re: FOP Release Automation
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 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
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 : > 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 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 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
