You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Robert Meyer <rm...@hotmail.co.uk> on 2014/05/21 11:24:35 UTC
FOP Release Automation
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
Re: FOP Release Automation
Posted by Clay Leeds <th...@gmail.com>.
On Jul 24, 2014, at 9:45 AM, Vincent Hennebert <vh...@gmail.com> wrote:
> [Moving to general@ as other sub-projects can benefit from this too.]
>
> I thought I would have a go at it and believe I’ve found a solution.
> There was a problem of conflicting syntaxes between Markdown’s way of
> specifying custom header IDs, and Dotiac::DTL’s syntax for comments.
Sounds like a good solution.
> For example:
>
> ## Project Status {#status}
>
> The ‘{#status}’ is Mardown’s way of giving a custom ID to the generated
> H2 element. But ‘{#’ is also a way to introduce a comment in
> a Dotiac::DTL template, which then complains that there is no closing
> ‘#}’.
>
> Fortunately, both can be made to agree by inserting a space between ‘{’
> and ‘#’:
>
> ## Project Status { #status}
>
> The Dotiac:DTL comment has now gone, but Markdown still recognises it as
> a custom ID. (A lot of them are actually unnecessary since they are
> identical to the title, and would be automatically generated by the
> Markdown HeaderId extension. They come from the conversion of Forrest
> sources, at some point we may want to scan through and remove them.)
Yeah. I implemented that change, so we could have TOC-style links. At the time I didn't believe the Titles would be auto-generated.
> As you may have noticed I’ve just committed a batch change of header IDs
> that introduces that space. Now we can enable pre-processing of the
> Markdown sources and enjoy the use of variables (and much more if you are
> daring).
>
> Fortunately there’s hardly any Perl involved. We just need to set some
> parameters in the path.pm and define variables there. See
> http://svn.apache.org/r1613178 for more details. I’ve added just two
> variables as a proof of concept but now we can proceed scanning the
> sources and adding more variables.
>
> I don’t know whether there’s a risk that our variables conflict with the
> CMS’ own variables. If we name them properly (e.g., prefixing them with
> fop_ or batik_ or xgc_), then this should not happen.
>
> Vincent
+1 from me.
Nice that we can implement this by defining those vars in lib/path.pm and the perl fix is so simple.
Clay
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
RE: FOP Release Automation
Posted by Robert Meyer <rm...@hotmail.co.uk>.
Hi Vincent,
I actually replied to this yesterday from my phone after you posted but it seemed to get lost in the ether. No comments about my phone Vincent! ;-) Really well done on finding this out as the '#}' message was the major stumbling block I was having during my investigations. I guess I was right in my assumptions that it was having issues with our site but it's good that it's been rectified with such a simple change.
Robert
> Date: Fri, 25 Jul 2014 10:26:57 +0100
> From: bowditch_chris@hotmail.com
> To: general@xmlgraphics.apache.org
> Subject: Re: FOP Release Automation
>
> Hi Vincent,
>
> On 24/07/2014 17:45, Vincent Hennebert wrote:
> > [Moving to general@ as other sub-projects can benefit from this too.]
> >
> > I thought I would have a go at it and believe I’ve found a solution.
> > There was a problem of conflicting syntaxes between Markdown’s way of
> > specifying custom header IDs, and Dotiac::DTL’s syntax for comments.
>
> That's great news. Well done Vincent! Now we just need someone to add
> all the variables we need and write a script to change the variables at
> release time.
>
> >
> > For example:
> >
> > ## Project Status {#status}
> >
> > The ‘{#status}’ is Mardown’s way of giving a custom ID to the generated
> > H2 element. But ‘{#’ is also a way to introduce a comment in
> > a Dotiac::DTL template, which then complains that there is no closing
> > ‘#}’.
> >
> > Fortunately, both can be made to agree by inserting a space between ‘{’
> > and ‘#’:
> >
> > ## Project Status { #status}
> >
> > The Dotiac:DTL comment has now gone, but Markdown still recognises it as
> > a custom ID. (A lot of them are actually unnecessary since they are
> > identical to the title, and would be automatically generated by the
> > Markdown HeaderId extension. They come from the conversion of Forrest
> > sources, at some point we may want to scan through and remove them.)
> >
> > As you may have noticed I’ve just committed a batch change of header IDs
> > that introduces that space. Now we can enable pre-processing of the
> > Markdown sources and enjoy the use of variables (and much more if you are
> > daring).
> >
> > Fortunately there’s hardly any Perl involved. We just need to set some
> > parameters in the path.pm and define variables there. See
> > http://svn.apache.org/r1613178 for more details. I’ve added just two
> > variables as a proof of concept but now we can proceed scanning the
> > sources and adding more variables.
> >
> > I don’t know whether there’s a risk that our variables conflict with the
> > CMS’ own variables. If we name them properly (e.g., prefixing them with
> > fop_ or batik_ or xgc_), then this should not happen.
> >
> > Vincent
>
> Thanks,
>
> Chris
>
> >
> >
> > On 15/07/14 11:35, 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_chris@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 <rmeyer@hotmail.co.uk
> >> > > <ma...@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: simonsteiner1984@gmail.com
> >> <ma...@gmail.com>
> >> > >> To: fop-dev@xmlgraphics.apache.org
> >> > >> <ma...@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:rmeyer@hotmail.co.uk]
> >> > >> *Sent:*30 May 2014 14:05
> >> > >> *To:*fop-dev@xmlgraphics.apache.org
> >> > >> <ma...@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
> >> > >
> >> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail: general-help@xmlgraphics.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: general-help@xmlgraphics.apache.org
>
Re: FOP Release Automation
Posted by Chris Bowditch <bo...@hotmail.com>.
Hi Vincent,
On 24/07/2014 17:45, Vincent Hennebert wrote:
> [Moving to general@ as other sub-projects can benefit from this too.]
>
> I thought I would have a go at it and believe I’ve found a solution.
> There was a problem of conflicting syntaxes between Markdown’s way of
> specifying custom header IDs, and Dotiac::DTL’s syntax for comments.
That's great news. Well done Vincent! Now we just need someone to add
all the variables we need and write a script to change the variables at
release time.
>
> For example:
>
> ## Project Status {#status}
>
> The ‘{#status}’ is Mardown’s way of giving a custom ID to the generated
> H2 element. But ‘{#’ is also a way to introduce a comment in
> a Dotiac::DTL template, which then complains that there is no closing
> ‘#}’.
>
> Fortunately, both can be made to agree by inserting a space between ‘{’
> and ‘#’:
>
> ## Project Status { #status}
>
> The Dotiac:DTL comment has now gone, but Markdown still recognises it as
> a custom ID. (A lot of them are actually unnecessary since they are
> identical to the title, and would be automatically generated by the
> Markdown HeaderId extension. They come from the conversion of Forrest
> sources, at some point we may want to scan through and remove them.)
>
> As you may have noticed I’ve just committed a batch change of header IDs
> that introduces that space. Now we can enable pre-processing of the
> Markdown sources and enjoy the use of variables (and much more if you are
> daring).
>
> Fortunately there’s hardly any Perl involved. We just need to set some
> parameters in the path.pm and define variables there. See
> http://svn.apache.org/r1613178 for more details. I’ve added just two
> variables as a proof of concept but now we can proceed scanning the
> sources and adding more variables.
>
> I don’t know whether there’s a risk that our variables conflict with the
> CMS’ own variables. If we name them properly (e.g., prefixing them with
> fop_ or batik_ or xgc_), then this should not happen.
>
> Vincent
Thanks,
Chris
>
>
> On 15/07/14 11:35, 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_chris@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 <rmeyer@hotmail.co.uk
>> > > <ma...@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: simonsteiner1984@gmail.com
>> <ma...@gmail.com>
>> > >> To: fop-dev@xmlgraphics.apache.org
>> > >> <ma...@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:rmeyer@hotmail.co.uk]
>> > >> *Sent:*30 May 2014 14:05
>> > >> *To:*fop-dev@xmlgraphics.apache.org
>> > >> <ma...@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
>> > >
>> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: general-help@xmlgraphics.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: FOP Release Automation
Posted by Vincent Hennebert <vh...@gmail.com>.
[Moving to general@ as other sub-projects can benefit from this too.]
I thought I would have a go at it and believe I’ve found a solution.
There was a problem of conflicting syntaxes between Markdown’s way of
specifying custom header IDs, and Dotiac::DTL’s syntax for comments.
For example:
## Project Status {#status}
The ‘{#status}’ is Mardown’s way of giving a custom ID to the generated
H2 element. But ‘{#’ is also a way to introduce a comment in
a Dotiac::DTL template, which then complains that there is no closing
‘#}’.
Fortunately, both can be made to agree by inserting a space between ‘{’
and ‘#’:
## Project Status { #status}
The Dotiac:DTL comment has now gone, but Markdown still recognises it as
a custom ID. (A lot of them are actually unnecessary since they are
identical to the title, and would be automatically generated by the
Markdown HeaderId extension. They come from the conversion of Forrest
sources, at some point we may want to scan through and remove them.)
As you may have noticed I’ve just committed a batch change of header IDs
that introduces that space. Now we can enable pre-processing of the
Markdown sources and enjoy the use of variables (and much more if you are
daring).
Fortunately there’s hardly any Perl involved. We just need to set some
parameters in the path.pm and define variables there. See
http://svn.apache.org/r1613178 for more details. I’ve added just two
variables as a proof of concept but now we can proceed scanning the
sources and adding more variables.
I don’t know whether there’s a risk that our variables conflict with the
CMS’ own variables. If we name them properly (e.g., prefixing them with
fop_ or batik_ or xgc_), then this should not happen.
Vincent
On 15/07/14 11:35, 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_chris@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 <rmeyer@hotmail.co.uk
> > > <ma...@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: simonsteiner1984@gmail.com <ma...@gmail.com>
> > >> To: fop-dev@xmlgraphics.apache.org
> > >> <ma...@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:rmeyer@hotmail.co.uk]
> > >> *Sent:*30 May 2014 14:05
> > >> *To:*fop-dev@xmlgraphics.apache.org
> > >> <ma...@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
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
RE: FOP Release Automation
Posted by Robert Meyer <rm...@hotmail.co.uk>.
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.webmaestro@gmail.com
> Date: Tue, 15 Jul 2014 07:53:19 -0700
> To: fop-dev@xmlgraphics.apache.org
>
> On Jul 15, 2014, at 7:46 AM, Glenn Adams <gl...@skynav.com> wrote:
> > I suppose it depends on whether or not we need to hack perl to use the facility. If there is any alternative that doesn't use perl, then that would be preferable.
> >
> > Frankly, I've never been happy with the new MD based documentation, though Clay has spent an inordinate amount of time tweaking it.
>
> Yeah... It's not my favorite either, but at least edits are pretty quick, saved to SVN and we've got a solution to incorporate javadoc, etc.
>
> In the meantime, please let me know when we're ready to update the documentation for the Release. It doesn't take me very long to go through the code to make these types of batch edits. I'm good at this, and who knows, I might even spend the time to write some bash script to help us with the deployment! (you don't have anything against BASH, do ya Glenn?) :-p) (I think that's how to write a smiley with a tongue-in-cheek? :-D)
Re: FOP Release Automation
Posted by Glenn Adams <gl...@skynav.com>.
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 <th...@gmail.com>
wrote:
> On Jul 15, 2014, at 7:46 AM, Glenn Adams <gl...@skynav.com> wrote:
> > I suppose it depends on whether or not we need to hack perl to use the
> facility. If there is any alternative that doesn't use perl, then that
> would be preferable.
> >
> > Frankly, I've never been happy with the new MD based documentation,
> though Clay has spent an inordinate amount of time tweaking it.
>
> Yeah... It's not my favorite either, but at least edits are pretty quick,
> saved to SVN and we've got a solution to incorporate javadoc, etc.
>
> In the meantime, please let me know when we're ready to update the
> documentation for the Release. It doesn't take me very long to go through
> the code to make these types of batch edits. I'm good at this, and who
> knows, I might even spend the time to write some bash script to help us
> with the deployment! (you don't have anything against BASH, do ya Glenn?)
> :-p) (I think that's how to write a smiley with a tongue-in-cheek? :-D)
Re: New FOP Release [was: Re: FOP Release Automation]
Posted by Glenn Adams <gl...@skynav.com>.
On Thu, Jul 24, 2014 at 9:08 AM, Chris Bowditch <bo...@hotmail.com>
wrote:
> Hi Glenn,
>
>
> On 24/07/2014 14:41, Glenn Adams wrote:
>
>> On Thu, Jul 24, 2014 at 6:39 AM, Chris Bowditch <
>> bowditch_chris@hotmail.com>
>> wrote:
>>
>> 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.
>>>
>>> Is there a schedule (tentative or otherwise) for releasing PDFBox 2.0?
>>
>
> The PDFBox board report for July 2014, says they are targeting late summer.
>
If that is a realistic target, then we should wait for the 2.0 release IMO.
>
> Thanks,
>
> Chris
>
>
>>
>> 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
>>>
>>> Sure.
>>
>>
>> Thanks,
>>>
>>> Chris
>>>
>>> On 16/07/2014 18:33, Glenn Adams wrote:
>>>
>>>
>>>>
>>>> On Wed, Jul 16, 2014 at 11:23 AM, Vincent Hennebert <
>>>> vhennebert@gmail.com
>>>> <ma...@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:vhennebert@gmail.com
>>>> <ma...@gmail.com>]
>>>> Sent: 16 July 2014 12:56
>>>> To: fop-dev@xmlgraphics.apache.org
>>>> <ma...@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 <glenn@skynav.com
>>>> <ma...@skynav.com>> wrote:
>>>>
>>>> I suppose it depends on whether or not we need to hack
>>>> perl to use the facility. If there is any alternative
>>>> that doesn't use perl, then that would be preferable.
>>>>
>>>> Frankly, I've never been happy with the new MD based
>>>> documentation, though Clay has spent an inordinate
>>>> amount of time tweaking it.
>>>>
>>>>
>>>> Yeah... It's not my favorite either, but at least edits
>>>> are pretty quick, saved to SVN and we've got a solution to
>>>> incorporate javadoc, etc.
>>>>
>>>> In the meantime, please let me know when we're ready to
>>>> update the
>>>> documentation for the Release. It doesn't take me very
>>>> long to go
>>>> through the code to make these types of batch edits.
>>>>
>>>> <snip/>
>>>>
>>>> Clay, your offer to help would be greatly appreciated!
>>>>
>>>> And since you’re mentioning it, maybe it’s time to think about
>>>> making a new release of FOP. Although now that the font
>>>> merging code has been merged to trunk, and introduces a
>>>> dependency on FontBox 2.0.0, we would have to wait that
>>>> FontBox 2.0.0 is released first. Or adapt the code to keep the
>>>> former 1.8.5 dependency (or the newer 1.8.6 released version).
>>>>
>>>> In the meantime, can anybody think of features that should
>>>> definitely be implemented before the release, or bugs fixed?
>>>> Remember that due to API changes, that release will have to be
>>>> called 2.0.
>>>>
>>>> Thanks,
>>>> Vincent
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
>>> For additional commands, e-mail: general-help@xmlgraphics.apache.org
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: general-help@xmlgraphics.apache.org
>
>
Re: New FOP Release [was: Re: FOP Release Automation]
Posted by Chris Bowditch <bo...@hotmail.com>.
Hi Glenn,
On 24/07/2014 14:41, Glenn Adams wrote:
> On Thu, Jul 24, 2014 at 6:39 AM, Chris Bowditch <bo...@hotmail.com>
> wrote:
>
>> 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.
>>
> Is there a schedule (tentative or otherwise) for releasing PDFBox 2.0?
The PDFBox board report for July 2014, says they are targeting late summer.
Thanks,
Chris
>
>
>> 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
>>
> Sure.
>
>
>> Thanks,
>>
>> Chris
>>
>> On 16/07/2014 18:33, Glenn Adams wrote:
>>
>>>
>>>
>>> On Wed, Jul 16, 2014 at 11:23 AM, Vincent Hennebert <vhennebert@gmail.com
>>> <ma...@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:vhennebert@gmail.com
>>> <ma...@gmail.com>]
>>> Sent: 16 July 2014 12:56
>>> To: fop-dev@xmlgraphics.apache.org
>>> <ma...@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 <glenn@skynav.com
>>> <ma...@skynav.com>> wrote:
>>>
>>> I suppose it depends on whether or not we need to hack
>>> perl to use the facility. If there is any alternative
>>> that doesn't use perl, then that would be preferable.
>>>
>>> Frankly, I've never been happy with the new MD based
>>> documentation, though Clay has spent an inordinate
>>> amount of time tweaking it.
>>>
>>>
>>> Yeah... It's not my favorite either, but at least edits
>>> are pretty quick, saved to SVN and we've got a solution to
>>> incorporate javadoc, etc.
>>>
>>> In the meantime, please let me know when we're ready to
>>> update the
>>> documentation for the Release. It doesn't take me very
>>> long to go
>>> through the code to make these types of batch edits.
>>>
>>> <snip/>
>>>
>>> Clay, your offer to help would be greatly appreciated!
>>>
>>> And since you’re mentioning it, maybe it’s time to think about
>>> making a new release of FOP. Although now that the font
>>> merging code has been merged to trunk, and introduces a
>>> dependency on FontBox 2.0.0, we would have to wait that
>>> FontBox 2.0.0 is released first. Or adapt the code to keep the
>>> former 1.8.5 dependency (or the newer 1.8.6 released version).
>>>
>>> In the meantime, can anybody think of features that should
>>> definitely be implemented before the release, or bugs fixed?
>>> Remember that due to API changes, that release will have to be
>>> called 2.0.
>>>
>>> Thanks,
>>> Vincent
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: general-help@xmlgraphics.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: New FOP Release [was: Re: FOP Release Automation]
Posted by Glenn Adams <gl...@skynav.com>.
On Thu, Jul 24, 2014 at 6:39 AM, Chris Bowditch <bo...@hotmail.com>
wrote:
> 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.
>
Is there a schedule (tentative or otherwise) for releasing PDFBox 2.0?
>
> 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
>
Sure.
>
> Thanks,
>
> Chris
>
> On 16/07/2014 18:33, Glenn Adams wrote:
>
>>
>>
>>
>> On Wed, Jul 16, 2014 at 11:23 AM, Vincent Hennebert <vhennebert@gmail.com
>> <ma...@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:vhennebert@gmail.com
>> <ma...@gmail.com>]
>> Sent: 16 July 2014 12:56
>> To: fop-dev@xmlgraphics.apache.org
>> <ma...@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 <glenn@skynav.com
>> <ma...@skynav.com>> wrote:
>>
>> I suppose it depends on whether or not we need to hack
>> perl to use the facility. If there is any alternative
>> that doesn't use perl, then that would be preferable.
>>
>> Frankly, I've never been happy with the new MD based
>> documentation, though Clay has spent an inordinate
>> amount of time tweaking it.
>>
>>
>> Yeah... It's not my favorite either, but at least edits
>> are pretty quick, saved to SVN and we've got a solution to
>> incorporate javadoc, etc.
>>
>> In the meantime, please let me know when we're ready to
>> update the
>> documentation for the Release. It doesn't take me very
>> long to go
>> through the code to make these types of batch edits.
>>
>> <snip/>
>>
>> Clay, your offer to help would be greatly appreciated!
>>
>> And since you’re mentioning it, maybe it’s time to think about
>> making a new release of FOP. Although now that the font
>> merging code has been merged to trunk, and introduces a
>> dependency on FontBox 2.0.0, we would have to wait that
>> FontBox 2.0.0 is released first. Or adapt the code to keep the
>> former 1.8.5 dependency (or the newer 1.8.6 released version).
>>
>> In the meantime, can anybody think of features that should
>> definitely be implemented before the release, or bugs fixed?
>> Remember that due to API changes, that release will have to be
>> called 2.0.
>>
>> Thanks,
>> Vincent
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: general-help@xmlgraphics.apache.org
>
>
Re: New FOP Release [was: Re: FOP Release Automation]
Posted by Chris Bowditch <bo...@hotmail.com>.
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
> <vhennebert@gmail.com <ma...@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:vhennebert@gmail.com
> <ma...@gmail.com>]
> Sent: 16 July 2014 12:56
> To: fop-dev@xmlgraphics.apache.org
> <ma...@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 <glenn@skynav.com
> <ma...@skynav.com>> wrote:
>
> I suppose it depends on whether or not we need to hack
> perl to use the facility. If there is any alternative
> that doesn't use perl, then that would be preferable.
>
> Frankly, I've never been happy with the new MD based
> documentation, though Clay has spent an inordinate
> amount of time tweaking it.
>
>
> Yeah... It's not my favorite either, but at least edits
> are pretty quick, saved to SVN and we've got a solution to
> incorporate javadoc, etc.
>
> In the meantime, please let me know when we're ready to
> update the
> documentation for the Release. It doesn't take me very
> long to go
> through the code to make these types of batch edits.
>
> <snip/>
>
> Clay, your offer to help would be greatly appreciated!
>
> And since you’re mentioning it, maybe it’s time to think about
> making a new release of FOP. Although now that the font
> merging code has been merged to trunk, and introduces a
> dependency on FontBox 2.0.0, we would have to wait that
> FontBox 2.0.0 is released first. Or adapt the code to keep the
> former 1.8.5 dependency (or the newer 1.8.6 released version).
>
> In the meantime, can anybody think of features that should
> definitely be implemented before the release, or bugs fixed?
> Remember that due to API changes, that release will have to be
> called 2.0.
>
> Thanks,
> Vincent
>
>
Re: New FOP Release [was: Re: FOP Release Automation]
Posted by Chris Bowditch <bo...@hotmail.com>.
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
> <vhennebert@gmail.com <ma...@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:vhennebert@gmail.com
> <ma...@gmail.com>]
> Sent: 16 July 2014 12:56
> To: fop-dev@xmlgraphics.apache.org
> <ma...@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 <glenn@skynav.com
> <ma...@skynav.com>> wrote:
>
> I suppose it depends on whether or not we need to hack
> perl to use the facility. If there is any alternative
> that doesn't use perl, then that would be preferable.
>
> Frankly, I've never been happy with the new MD based
> documentation, though Clay has spent an inordinate
> amount of time tweaking it.
>
>
> Yeah... It's not my favorite either, but at least edits
> are pretty quick, saved to SVN and we've got a solution to
> incorporate javadoc, etc.
>
> In the meantime, please let me know when we're ready to
> update the
> documentation for the Release. It doesn't take me very
> long to go
> through the code to make these types of batch edits.
>
> <snip/>
>
> Clay, your offer to help would be greatly appreciated!
>
> And since you’re mentioning it, maybe it’s time to think about
> making a new release of FOP. Although now that the font
> merging code has been merged to trunk, and introduces a
> dependency on FontBox 2.0.0, we would have to wait that
> FontBox 2.0.0 is released first. Or adapt the code to keep the
> former 1.8.5 dependency (or the newer 1.8.6 released version).
>
> In the meantime, can anybody think of features that should
> definitely be implemented before the release, or bugs fixed?
> Remember that due to API changes, that release will have to be
> called 2.0.
>
> Thanks,
> Vincent
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: New FOP Release [was: Re: FOP Release Automation]
Posted by Glenn Adams <gl...@skynav.com>.
On Wed, Jul 16, 2014 at 11:23 AM, Vincent Hennebert <vh...@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:vhennebert@gmail.com]
>> Sent: 16 July 2014 12:56
>> To: fop-dev@xmlgraphics.apache.org
>> Subject: New FOP Release [was: Re: FOP Release Automation]
>>
>> Hi,
>>
>> On 15/07/14 16:53, Clay Leeds wrote:
>>
>>> On Jul 15, 2014, at 7:46 AM, Glenn Adams <gl...@skynav.com> wrote:
>>>
>>>> I suppose it depends on whether or not we need to hack perl to use the
>>>> facility. If there is any alternative that doesn't use perl, then that
>>>> would be preferable.
>>>>
>>>> Frankly, I've never been happy with the new MD based documentation,
>>>> though Clay has spent an inordinate amount of time tweaking it.
>>>>
>>>
>>> Yeah... It's not my favorite either, but at least edits are pretty
>>> quick, saved to SVN and we've got a solution to incorporate javadoc, etc.
>>>
>>> In the meantime, please let me know when we're ready to update the
>>> documentation for the Release. It doesn't take me very long to go
>>> through the code to make these types of batch edits.
>>>
>> <snip/>
>>
>> Clay, your offer to help would be greatly appreciated!
>>
>> And since you’re mentioning it, maybe it’s time to think about making a
>> new release of FOP. Although now that the font merging code has been merged
>> to trunk, and introduces a dependency on FontBox 2.0.0, we would have to
>> wait that FontBox 2.0.0 is released first. Or adapt the code to keep the
>> former 1.8.5 dependency (or the newer 1.8.6 released version).
>>
>> In the meantime, can anybody think of features that should definitely be
>> implemented before the release, or bugs fixed? Remember that due to API
>> changes, that release will have to be called 2.0.
>>
>> Thanks,
>> Vincent
>>
>>
Re: New FOP Release [was: Re: FOP Release Automation]
Posted by Vincent Hennebert <vh...@gmail.com>.
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:vhennebert@gmail.com]
> Sent: 16 July 2014 12:56
> To: fop-dev@xmlgraphics.apache.org
> Subject: New FOP Release [was: Re: FOP Release Automation]
>
> Hi,
>
> On 15/07/14 16:53, Clay Leeds wrote:
>> On Jul 15, 2014, at 7:46 AM, Glenn Adams <gl...@skynav.com> wrote:
>>> I suppose it depends on whether or not we need to hack perl to use the facility. If there is any alternative that doesn't use perl, then that would be preferable.
>>>
>>> Frankly, I've never been happy with the new MD based documentation, though Clay has spent an inordinate amount of time tweaking it.
>>
>> Yeah... It's not my favorite either, but at least edits are pretty quick, saved to SVN and we've got a solution to incorporate javadoc, etc.
>>
>> In the meantime, please let me know when we're ready to update the
>> documentation for the Release. It doesn't take me very long to go
>> through the code to make these types of batch edits.
> <snip/>
>
> Clay, your offer to help would be greatly appreciated!
>
> And since you’re mentioning it, maybe it’s time to think about making a new release of FOP. Although now that the font merging code has been merged to trunk, and introduces a dependency on FontBox 2.0.0, we would have to wait that FontBox 2.0.0 is released first. Or adapt the code to keep the former 1.8.5 dependency (or the newer 1.8.6 released version).
>
> In the meantime, can anybody think of features that should definitely be implemented before the release, or bugs fixed? Remember that due to API changes, that release will have to be called 2.0.
>
> Thanks,
> Vincent
>
RE: New FOP Release [was: Re: FOP Release Automation]
Posted by Simon Steiner <si...@gmail.com>.
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:vhennebert@gmail.com]
Sent: 16 July 2014 12:56
To: fop-dev@xmlgraphics.apache.org
Subject: New FOP Release [was: Re: FOP Release Automation]
Hi,
On 15/07/14 16:53, Clay Leeds wrote:
> On Jul 15, 2014, at 7:46 AM, Glenn Adams <gl...@skynav.com> wrote:
>> I suppose it depends on whether or not we need to hack perl to use the facility. If there is any alternative that doesn't use perl, then that would be preferable.
>>
>> Frankly, I've never been happy with the new MD based documentation, though Clay has spent an inordinate amount of time tweaking it.
>
> Yeah... It's not my favorite either, but at least edits are pretty quick, saved to SVN and we've got a solution to incorporate javadoc, etc.
>
> In the meantime, please let me know when we're ready to update the
> documentation for the Release. It doesn't take me very long to go
> through the code to make these types of batch edits.
<snip/>
Clay, your offer to help would be greatly appreciated!
And since you’re mentioning it, maybe it’s time to think about making a new release of FOP. Although now that the font merging code has been merged to trunk, and introduces a dependency on FontBox 2.0.0, we would have to wait that FontBox 2.0.0 is released first. Or adapt the code to keep the former 1.8.5 dependency (or the newer 1.8.6 released version).
In the meantime, can anybody think of features that should definitely be implemented before the release, or bugs fixed? Remember that due to API changes, that release will have to be called 2.0.
Thanks,
Vincent
New FOP Release [was: Re: FOP Release Automation]
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi,
On 15/07/14 16:53, Clay Leeds wrote:
> On Jul 15, 2014, at 7:46 AM, Glenn Adams <gl...@skynav.com> wrote:
>> I suppose it depends on whether or not we need to hack perl to use the facility. If there is any alternative that doesn't use perl, then that would be preferable.
>>
>> Frankly, I've never been happy with the new MD based documentation, though Clay has spent an inordinate amount of time tweaking it.
>
> Yeah... It's not my favorite either, but at least edits are pretty quick, saved to SVN and we've got a solution to incorporate javadoc, etc.
>
> In the meantime, please let me know when we're ready to update the
> documentation for the Release. It doesn't take me very long to go
> through the code to make these types of batch edits.
<snip/>
Clay, your offer to help would be greatly appreciated!
And since you’re mentioning it, maybe it’s time to think about making
a new release of FOP. Although now that the font merging code has been
merged to trunk, and introduces a dependency on FontBox 2.0.0, we would
have to wait that FontBox 2.0.0 is released first. Or adapt the code to
keep the former 1.8.5 dependency (or the newer 1.8.6 released version).
In the meantime, can anybody think of features that should definitely be
implemented before the release, or bugs fixed? Remember that due to API
changes, that release will have to be called 2.0.
Thanks,
Vincent
Re: FOP Release Automation
Posted by Clay Leeds <th...@gmail.com>.
On Jul 15, 2014, at 7:46 AM, Glenn Adams <gl...@skynav.com> wrote:
> I suppose it depends on whether or not we need to hack perl to use the facility. If there is any alternative that doesn't use perl, then that would be preferable.
>
> Frankly, I've never been happy with the new MD based documentation, though Clay has spent an inordinate amount of time tweaking it.
Yeah... It's not my favorite either, but at least edits are pretty quick, saved to SVN and we've got a solution to incorporate javadoc, etc.
In the meantime, please let me know when we're ready to update the documentation for the Release. It doesn't take me very long to go through the code to make these types of batch edits. I'm good at this, and who knows, I might even spend the time to write some bash script to help us with the deployment! (you don't have anything against BASH, do ya Glenn?) :-p) (I think that's how to write a smiley with a tongue-in-cheek? :-D)
Re: FOP Release Automation
Posted by Glenn Adams <gl...@skynav.com>.
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 <th...@gmail.com>
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 <gl...@skynav.com> wrote:
>
> I will -1 any proposal that involves using Perl.
>
>
> On Tue, Jul 15, 2014 at 3:35 AM, Robert Meyer <rm...@hotmail.co.uk>
> 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_chris@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 <rmeyer@hotmail.co.uk
>> > > <ma...@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: simonsteiner1984@gmail.com <ma...@gmail.com>
>> > >> To: fop-dev@xmlgraphics.apache.org
>> > >> <ma...@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:rmeyer@hotmail.co.uk]
>> > >> *Sent:*30 May 2014 14:05
>> > >> *To:*fop-dev@xmlgraphics.apache.org
>> > >> <ma...@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
Posted by Clay Leeds <th...@gmail.com>.
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 <gl...@skynav.com> wrote:
>
> I will -1 any proposal that involves using Perl.
>
>
>> On Tue, Jul 15, 2014 at 3:35 AM, Robert Meyer <rm...@hotmail.co.uk> 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_chris@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 <rmeyer@hotmail.co.uk
>> > > <ma...@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: simonsteiner1984@gmail.com <ma...@gmail.com>
>> > >> To: fop-dev@xmlgraphics.apache.org
>> > >> <ma...@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:rmeyer@hotmail.co.uk]
>> > >> *Sent:*30 May 2014 14:05
>> > >> *To:*fop-dev@xmlgraphics.apache.org
>> > >> <ma...@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
Posted by Glenn Adams <gl...@skynav.com>.
I will -1 any proposal that involves using Perl.
On Tue, Jul 15, 2014 at 3:35 AM, Robert Meyer <rm...@hotmail.co.uk> 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_chris@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 <rmeyer@hotmail.co.uk
> > > <ma...@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: simonsteiner1984@gmail.com <ma...@gmail.com>
> > >> To: fop-dev@xmlgraphics.apache.org
> > >> <ma...@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:rmeyer@hotmail.co.uk]
> > >> *Sent:*30 May 2014 14:05
> > >> *To:*fop-dev@xmlgraphics.apache.org
> > >> <ma...@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
Posted by Robert Meyer <rm...@hotmail.co.uk>.
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_chris@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 <rmeyer@hotmail.co.uk
> > <ma...@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: simonsteiner1984@gmail.com <ma...@gmail.com>
> >> To: fop-dev@xmlgraphics.apache.org
> >> <ma...@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:rmeyer@hotmail.co.uk]
> >> *Sent:*30 May 2014 14:05
> >> *To:*fop-dev@xmlgraphics.apache.org
> >> <ma...@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
Posted by Chris Bowditch <bo...@hotmail.com>.
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 <rmeyer@hotmail.co.uk
> <ma...@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: simonsteiner1984@gmail.com <ma...@gmail.com>
>> To: fop-dev@xmlgraphics.apache.org
>> <ma...@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:rmeyer@hotmail.co.uk]
>> *Sent:*30 May 2014 14:05
>> *To:*fop-dev@xmlgraphics.apache.org
>> <ma...@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
Posted by Clay Leeds <th...@gmail.com>.
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 <rm...@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: simonsteiner1984@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:rmeyer@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
Posted by Robert Meyer <rm...@hotmail.co.uk>.
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: simonsteiner1984@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:rmeyer@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
Posted by Simon Steiner <si...@gmail.com>.
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:rmeyer@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
Posted by Robert Meyer <rm...@hotmail.co.uk>.
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
Posted by Pascal Sancho <ps...@gmail.com>.
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 <rm...@hotmail.co.uk>:
> Hi Clay and Pascal,
>
> Sorry for my late reply with this.
>
> Pascal your idea makes a lot of sense as that will keep all versioned docs
> with their associated FOP version. I haven't had much of a chance to look at
> this over the last couple of days but am planning on spending some time in
> the coming days.
>
> Clay, both of what you mention sound intriguing so I'll take a look at
> those. I think updating it manually will be a last resort as even just
> writing an ant script would be preferable! If it does come to a script, the
> idea of copying the trunk folder and doing a find / replace on say "trunk"
> and replacing with "2.0" would be an option (with some caveats), but I'll
> investigate the other methods first.
>
> I'll keep you posted.
>
> Regards,
>
> Robert Meyer
>
>> Subject: Re: FOP Release Automation
>> From: the.webmaestro@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 <ps...@gmail.com> wrote:
>> > Hi,
>> >
>> > The FOP package should not embed the whole website, but only the
>> > documentation part, more precisely only the relevant version folder.
>> >
>> > Currently, FOP doc folder is referenced as svn:externals in FOP repo,
>> > resulting on extra irrelevant info, such as other versions,
>> > miscellaneous processes, general info, etc.
>> >
>> > IMHO, FOP versionned doc should be in FOP repo, and Website repo
>> > should refer to each FOP versionned doc through svn:externals prop.
>> >
>> > WDYT?
>>
>> +1 Pascal... Makes sense to me. There's a lot of cruft in there...
>>
>> We'd have to either `svn:externals` a bunch of single files (svn-1.7+), or
>> adjust the site a bit to move the OLD versions somewhere 'out of the way'...
>> (And then add 301 redirects... ;-)
>>
>> Cheers!
>>
>> Clay Leeds @ the.webmaestro@gmail.com
>> "My religion is simple. My religion is kindness."
>> HH the Dalai Lama of Tibet
>>
--
pascal
RE: FOP Release Automation
Posted by Robert Meyer <rm...@hotmail.co.uk>.
Hi Clay and Pascal,
Sorry for my late reply with this.
Pascal your idea makes a lot of sense as that will keep all versioned docs with their associated FOP version. I haven't had much of a chance to look at this over the last couple of days but am planning on spending some time in the coming days.
Clay, both of what you mention sound intriguing so I'll take a look at those. I think updating it manually will be a last resort as even just writing an ant script would be preferable! If it does come to a script, the idea of copying the trunk folder and doing a find / replace on say "trunk" and replacing with "2.0" would be an option (with some caveats), but I'll investigate the other methods first.
I'll keep you posted.
Regards,
Robert Meyer
> Subject: Re: FOP Release Automation
> From: the.webmaestro@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 <ps...@gmail.com> wrote:
> > Hi,
> >
> > The FOP package should not embed the whole website, but only the
> > documentation part, more precisely only the relevant version folder.
> >
> > Currently, FOP doc folder is referenced as svn:externals in FOP repo,
> > resulting on extra irrelevant info, such as other versions,
> > miscellaneous processes, general info, etc.
> >
> > IMHO, FOP versionned doc should be in FOP repo, and Website repo
> > should refer to each FOP versionned doc through svn:externals prop.
> >
> > WDYT?
>
> +1 Pascal... Makes sense to me. There's a lot of cruft in there...
>
> We'd have to either `svn:externals` a bunch of single files (svn-1.7+), or adjust the site a bit to move the OLD versions somewhere 'out of the way'... (And then add 301 redirects... ;-)
>
> Cheers!
>
> Clay Leeds @ the.webmaestro@gmail.com
> "My religion is simple. My religion is kindness."
> HH the Dalai Lama of Tibet
>
Re: FOP Release Automation
Posted by Pascal Sancho <ps...@gmail.com>.
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 <th...@gmail.com>:
> 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 <ps...@gmail.com> wrote:
>> Hi,
>>
>> The FOP package should not embed the whole website, but only the
>> documentation part, more precisely only the relevant version folder.
>>
>> Currently, FOP doc folder is referenced as svn:externals in FOP repo,
>> resulting on extra irrelevant info, such as other versions,
>> miscellaneous processes, general info, etc.
>>
>> IMHO, FOP versionned doc should be in FOP repo, and Website repo
>> should refer to each FOP versionned doc through svn:externals prop.
>>
>> WDYT?
>
> +1 Pascal... Makes sense to me. There's a lot of cruft in there...
>
> We'd have to either `svn:externals` a bunch of single files (svn-1.7+), or adjust the site a bit to move the OLD versions somewhere 'out of the way'... (And then add 301 redirects... ;-)
--
pascal
Re: FOP Release Automation
Posted by Clay Leeds <th...@gmail.com>.
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 <ps...@gmail.com> wrote:
> Hi,
>
> The FOP package should not embed the whole website, but only the
> documentation part, more precisely only the relevant version folder.
>
> Currently, FOP doc folder is referenced as svn:externals in FOP repo,
> resulting on extra irrelevant info, such as other versions,
> miscellaneous processes, general info, etc.
>
> IMHO, FOP versionned doc should be in FOP repo, and Website repo
> should refer to each FOP versionned doc through svn:externals prop.
>
> WDYT?
+1 Pascal... Makes sense to me. There's a lot of cruft in there...
We'd have to either `svn:externals` a bunch of single files (svn-1.7+), or adjust the site a bit to move the OLD versions somewhere 'out of the way'... (And then add 301 redirects... ;-)
Cheers!
Clay Leeds @ the.webmaestro@gmail.com
"My religion is simple. My religion is kindness."
HH the Dalai Lama of Tibet
Re: FOP Release Automation
Posted by Pascal Sancho <ps...@gmail.com>.
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 <th...@gmail.com>:
> Thank you for looking at this, Robert. I'll take a look at MarkDown
> solutions as well.
>
> Cheers!
>
> Clay
>
> --
>
> "My religion is simple. My religion is kindness."
> - HH The Dalai Lama of Tibet
>
>
> On May 21, 2014, at 2:24 AM, Robert Meyer <rm...@hotmail.co.uk> wrote:
>
> Hi All,
>
> I've been asked to look at a way to automate the FOP release process with
> regards the website documentation. At the moment every new release requires
> the following:
>
> 1) Download the site from SVN
> 2) Copy the folder containing the latest version's markdown files (1.1 for
> example) and rename to the new version
> 3) Go through all the files manually and update all the references from the
> old to the new version
> 4) Update any markdown files in the main directory with regard to the
> current and previous versions.
> 5) Delete the oldest version folder as we need only mantain the last 3.
> 6) Check and resubmit all files back to SVN
>
> My initial thought would to have a master copy in a separate directory. That
> copy would contain a tag in place where the version is given which could be
> substituted by a script of some kind (ant has a facility to do this). The
> ant script would also perform all of the above tasks so the only thing left
> to the user will be to check the output and push the new files. The problem
> I have with this is that SVN is not the only way in which the files can be
> edited as there is the web interface. If someone were to edit the files from
> there, the master copies would become out of date and worse, if someone were
> to perform a release it would overwrite all those changes.
>
> I've been recommended to look at markdown extensions but if anyone else has
> any ideas on the best way to go about this it would be much appreciated.
>
> Thanks,
>
> Robert Meyer
--
pascal
Re: FOP Release Automation
Posted by Clay Leeds <th...@gmail.com>.
Thank you for looking at this, Robert. I'll take a look at MarkDown solutions as well.
Cheers!
Clay
--
"My religion is simple. My religion is kindness."
- HH The Dalai Lama of Tibet
> On May 21, 2014, at 2:24 AM, Robert Meyer <rm...@hotmail.co.uk> wrote:
>
> Hi All,
>
> I've been asked to look at a way to automate the FOP release process with regards the website documentation. At the moment every new release requires the following:
>
> 1) Download the site from SVN
> 2) Copy the folder containing the latest version's markdown files (1.1 for example) and rename to the new version
> 3) Go through all the files manually and update all the references from the old to the new version
> 4) Update any markdown files in the main directory with regard to the current and previous versions.
> 5) Delete the oldest version folder as we need only mantain the last 3.
> 6) Check and resubmit all files back to SVN
>
> My initial thought would to have a master copy in a separate directory. That copy would contain a tag in place where the version is given which could be substituted by a script of some kind (ant has a facility to do this). The ant script would also perform all of the above tasks so the only thing left to the user will be to check the output and push the new files. The problem I have with this is that SVN is not the only way in which the files can be edited as there is the web interface. If someone were to edit the files from there, the master copies would become out of date and worse, if someone were to perform a release it would overwrite all those changes.
>
> I've been recommended to look at markdown extensions but if anyone else has any ideas on the best way to go about this it would be much appreciated.
>
> Thanks,
>
> Robert Meyer