Re: FOP Release
On Wed, Apr 22, 2015 at 9:40 AM, Chris Bowditch bowditch_ch...@hotmail.com wrote: I agree, but as Simon pointed out PDFBox is not a dependency of FOP, but of PDF plug-in, which is a separate project with a separate release cycle. The PDF plug-in project is an optional dependency of FOP, not required for core functionality. So the proposal is just to release the FOP project, not PDF plug-in. This means anyone wishing to use PDF-plugin with the new release of FOP would need to build it from source code using a PDFBox snaphot. Not ideal, but we are long overdue a FOP release, and only a small number of users are using the PDF plug-in. So I'm +1 to this proposal. ok; that works for me... on another point, when can we transition to maven? our ant configurations are difficult to maintain and understand; we should modernize Thanks, Chris On 22/04/2015 14:28, Glenn Adams wrote: I'm not comfortable requiring use of a snapshot dependency. For example, that would prevent deployment to maven central. On Wed, Apr 22, 2015 at 1:18 AM, Chris Bowditch bowditch_ch...@hotmail.com mailto:bowditch_ch...@hotmail.com wrote: Hi Glen, Its expected that a -1 vote includes a justification. You may well be right, but we are not mind readers and have no idea what you are thinking... Thanks, Chris On 21/04/2015 16:32, Glenn Adams wrote: -1 On Tue, Apr 21, 2015 at 9:21 AM, Simon Steiner simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com wrote: Hi, Since Batik and XGC have been released, are we ready to release FOP? It has been said we can’t release PDF plugin using a snapshot release of PDFBox 2.0. PDFBox 1.8 is missing font parsing libraries we need for font merging. We could make release a PDF plugin beta release using snapshot of PDFBox or ask user to use PDF plugin snapshot version with FOP 2.0. Thanks
Re: FOP Release
I think that maven will be embraced as soon as there is a volunteer to do the transition. On 4/22/15 6:13 PM, Glenn Adams wrote: On Wed, Apr 22, 2015 at 9:40 AM, Chris Bowditch bowditch_ch...@hotmail.com mailto:bowditch_ch...@hotmail.com wrote: I agree, but as Simon pointed out PDFBox is not a dependency of FOP, but of PDF plug-in, which is a separate project with a separate release cycle. The PDF plug-in project is an optional dependency of FOP, not required for core functionality. So the proposal is just to release the FOP project, not PDF plug-in. This means anyone wishing to use PDF-plugin with the new release of FOP would need to build it from source code using a PDFBox snaphot. Not ideal, but we are long overdue a FOP release, and only a small number of users are using the PDF plug-in. So I'm +1 to this proposal. ok; that works for me... on another point, when can we transition to maven? our ant configurations are difficult to maintain and understand; we should modernize Thanks, Chris On 22/04/2015 14:28, Glenn Adams wrote: I'm not comfortable requiring use of a snapshot dependency. For example, that would prevent deployment to maven central. On Wed, Apr 22, 2015 at 1:18 AM, Chris Bowditch bowditch_ch...@hotmail.com mailto:bowditch_ch...@hotmail.com mailto:bowditch_ch...@hotmail.com mailto:bowditch_ch...@hotmail.com wrote: Hi Glen, Its expected that a -1 vote includes a justification. You may well be right, but we are not mind readers and have no idea what you are thinking... Thanks, Chris On 21/04/2015 16:32, Glenn Adams wrote: -1 On Tue, Apr 21, 2015 at 9:21 AM, Simon Steiner simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com wrote: Hi, Since Batik and XGC have been released, are we ready to release FOP? It has been said we can’t release PDF plugin using a snapshot release of PDFBox 2.0. PDFBox 1.8 is missing font parsing libraries we need for font merging. We could make release a PDF plugin beta release using snapshot of PDFBox or ask user to use PDF plugin snapshot version with FOP 2.0. Thanks
Re: FOP Release
I agree, but as Simon pointed out PDFBox is not a dependency of FOP, but of PDF plug-in, which is a separate project with a separate release cycle. The PDF plug-in project is an optional dependency of FOP, not required for core functionality. So the proposal is just to release the FOP project, not PDF plug-in. This means anyone wishing to use PDF-plugin with the new release of FOP would need to build it from source code using a PDFBox snaphot. Not ideal, but we are long overdue a FOP release, and only a small number of users are using the PDF plug-in. So I'm +1 to this proposal. Thanks, Chris On 22/04/2015 14:28, Glenn Adams wrote: I'm not comfortable requiring use of a snapshot dependency. For example, that would prevent deployment to maven central. On Wed, Apr 22, 2015 at 1:18 AM, Chris Bowditch bowditch_ch...@hotmail.com mailto:bowditch_ch...@hotmail.com wrote: Hi Glen, Its expected that a -1 vote includes a justification. You may well be right, but we are not mind readers and have no idea what you are thinking... Thanks, Chris On 21/04/2015 16:32, Glenn Adams wrote: -1 On Tue, Apr 21, 2015 at 9:21 AM, Simon Steiner simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com wrote: Hi, Since Batik and XGC have been released, are we ready to release FOP? It has been said we can’t release PDF plugin using a snapshot release of PDFBox 2.0. PDFBox 1.8 is missing font parsing libraries we need for font merging. We could make release a PDF plugin beta release using snapshot of PDFBox or ask user to use PDF plugin snapshot version with FOP 2.0. Thanks
Re: FOP Release
Hi Glen, Its expected that a -1 vote includes a justification. You may well be right, but we are not mind readers and have no idea what you are thinking... Thanks, Chris On 21/04/2015 16:32, Glenn Adams wrote: -1 On Tue, Apr 21, 2015 at 9:21 AM, Simon Steiner simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com wrote: Hi, Since Batik and XGC have been released, are we ready to release FOP? It has been said we can’t release PDF plugin using a snapshot release of PDFBox 2.0. PDFBox 1.8 is missing font parsing libraries we need for font merging. We could make release a PDF plugin beta release using snapshot of PDFBox or ask user to use PDF plugin snapshot version with FOP 2.0. Thanks
Re: FOP Release
When I suggested releasing Batik back in December, Glenn mentioned that he wanted to fix some issues (namely https://issues.apache.org/jira/browse/FOP-2391) before releasing FOP 2.0. I assume this is the reason for -1, but I agree that a justification would help since not everyone may remember what was discussed in December. On 4/22/15 9:18 AM, Chris Bowditch wrote: Hi Glen, Its expected that a -1 vote includes a justification. You may well be right, but we are not mind readers and have no idea what you are thinking... Thanks, Chris On 21/04/2015 16:32, Glenn Adams wrote: -1 On Tue, Apr 21, 2015 at 9:21 AM, Simon Steiner simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com wrote: Hi, Since Batik and XGC have been released, are we ready to release FOP? It has been said we can’t release PDF plugin using a snapshot release of PDFBox 2.0. PDFBox 1.8 is missing font parsing libraries we need for font merging. We could make release a PDF plugin beta release using snapshot of PDFBox or ask user to use PDF plugin snapshot version with FOP 2.0. Thanks
FOP Release
Hi, Since Batik and XGC have been released, are we ready to release FOP? It has been said we can't release PDF plugin using a snapshot release of PDFBox 2.0. PDFBox 1.8 is missing font parsing libraries we need for font merging. We could make release a PDF plugin beta release using snapshot of PDFBox or ask user to use PDF plugin snapshot version with FOP 2.0. Thanks
Re: FOP Release
-1 On Tue, Apr 21, 2015 at 9:21 AM, Simon Steiner simonsteiner1...@gmail.com wrote: Hi, Since Batik and XGC have been released, are we ready to release FOP? It has been said we can’t release PDF plugin using a snapshot release of PDFBox 2.0. PDFBox 1.8 is missing font parsing libraries we need for font merging. We could make release a PDF plugin beta release using snapshot of PDFBox or ask user to use PDF plugin snapshot version with FOP 2.0. Thanks
RE: FOP Release
Hi, Its listed here https://xmlgraphics.apache.org/fop/trunk/running.html Thanks From: Clay Leeds [mailto:the.webmaes...@gmail.com] Sent: 21 April 2015 21:23 To: Apache FOP Subject: Re: FOP Release One of the changes for PDFBox 2.0.0 (from what I gather from the PDFBox ‘Ideas’ page), is a switch to Java 1.6. We discussed a switch for FOP that required a higher version of Java (I believe it was 1.6, but don’t recall). But I can’t find anywhere on our site that indicates what the minimum Java requirement actually is. I’d like to update the site to include the minimum requirements if someone can let me know what those are… ;-) Clay On Apr 21, 2015, at 8:21 AM, Simon Steiner simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com wrote: Hi, Since Batik and XGC have been released, are we ready to release FOP? It has been said we can’t release PDF plugin using a snapshot release of PDFBox 2.0. PDFBox 1.8 is missing font parsing libraries we need for font merging. We could make release a PDF plugin beta release using snapshot of PDFBox or ask user to use PDF plugin snapshot version with FOP 2.0. Thanks
Re: FOP Release
One of the changes for PDFBox 2.0.0 (from what I gather from the PDFBox ‘Ideas’ page), is a switch to Java 1.6. We discussed a switch for FOP that required a higher version of Java (I believe it was 1.6, but don’t recall). But I can’t find anywhere on our site that indicates what the minimum Java requirement actually is. I’d like to update the site to include the minimum requirements if someone can let me know what those are… ;-) Clay On Apr 21, 2015, at 8:21 AM, Simon Steiner simonsteiner1...@gmail.com wrote: Hi, Since Batik and XGC have been released, are we ready to release FOP? It has been said we can’t release PDF plugin using a snapshot release of PDFBox 2.0. PDFBox 1.8 is missing font parsing libraries we need for font merging. We could make release a PDF plugin beta release using snapshot of PDFBox or ask user to use PDF plugin snapshot version with FOP 2.0. Thanks
Re: Question on FOP release schedule
Hi Jacopo, Thanks for your contribution. I wonder why you ask for a bug fix release of 1.1? v2.0 will include all bug fixes since the v1.1 release, there are no plans for a 1.1.2 release or similar. We are working towards a v2.0 release of FOP. We've just released XML Graphics Commons v2.0, but the FOP release is dependent on other libraries being released first. Thanks, Chris On 03/10/2014 06:49, Jacopo Cappellato wrote: Thank you Luis, I have attached to Jira a Junit test for the CompareUtil.equal method that should prove the issue we are facing and should confirm that the fix I am proposing should work ok. As regards the bug fix release, at the moment this is the only issue that I am aware of that is causing some pain to OFBiz and having a bug fix release for it would be great; however I know that the release workflow requires a good amount of work and I am wondering if I or other OFBiz committers may be of any help in the release process (e.g. we could help the FOP community to maintain a release branch for 1.1 by backporting fixes to it and testing it). I am wide open to any suggestions. Of course OFBiz will upgrade to the new release 2.0 as soon as this will be available and we will help you to test that as well. All in all I am just trying to give something back to the FOP community, since the OFBiz community has been a rather silent and passive user of your amazing tool :-) Regards, Jacopo On Oct 3, 2014, at 1:15 AM, Luis Bernardo lmpmberna...@gmail.com wrote: I can apply your patch although I do not have the environment to test it. Regarding the question about a bug fix for 1.1, the answer is that there is nothing planned but if there is interest from the FOP users I think that can be accommodated. Is there any other bug your would like to see fixed in a 1.1+ release? On 10/2/14, 7:22 PM, Jacopo Cappellato wrote: Hi all, I am a committer for Apache OFBiz, a project that uses FOP 1.1 (thanks for this amazing product). I hope this is the right list to get some information about the release process and planning of Apache FOP. Apart from FOP 2.0, is there a plan to release a bug fix release for 1.1? For example, we may be specifically interested in getting a new release with this issue resolved: https://issues.apache.org/jira/browse/FOP-2157 (in the ticket I have attached a fix for the same). Is there something we could do to support you in the process? Thank you, Jacopo
Re: Question on FOP release schedule
Hi Chris, the only reason I have asked for a bug fix release for 1.1 is because it may be easier to approve/publish. But if you are already planning the new 2.0 release then great. Is there a tentative plan for it already? Thanks, Jacopo On Oct 7, 2014, at 2:36 PM, Chris Bowditch bowditch_ch...@hotmail.com wrote: Hi Jacopo, Thanks for your contribution. I wonder why you ask for a bug fix release of 1.1? v2.0 will include all bug fixes since the v1.1 release, there are no plans for a 1.1.2 release or similar. We are working towards a v2.0 release of FOP. We've just released XML Graphics Commons v2.0, but the FOP release is dependent on other libraries being released first. Thanks, Chris On 03/10/2014 06:49, Jacopo Cappellato wrote: Thank you Luis, I have attached to Jira a Junit test for the CompareUtil.equal method that should prove the issue we are facing and should confirm that the fix I am proposing should work ok. As regards the bug fix release, at the moment this is the only issue that I am aware of that is causing some pain to OFBiz and having a bug fix release for it would be great; however I know that the release workflow requires a good amount of work and I am wondering if I or other OFBiz committers may be of any help in the release process (e.g. we could help the FOP community to maintain a release branch for 1.1 by backporting fixes to it and testing it). I am wide open to any suggestions. Of course OFBiz will upgrade to the new release 2.0 as soon as this will be available and we will help you to test that as well. All in all I am just trying to give something back to the FOP community, since the OFBiz community has been a rather silent and passive user of your amazing tool :-) Regards, Jacopo On Oct 3, 2014, at 1:15 AM, Luis Bernardo lmpmberna...@gmail.com wrote: I can apply your patch although I do not have the environment to test it. Regarding the question about a bug fix for 1.1, the answer is that there is nothing planned but if there is interest from the FOP users I think that can be accommodated. Is there any other bug your would like to see fixed in a 1.1+ release? On 10/2/14, 7:22 PM, Jacopo Cappellato wrote: Hi all, I am a committer for Apache OFBiz, a project that uses FOP 1.1 (thanks for this amazing product). I hope this is the right list to get some information about the release process and planning of Apache FOP. Apart from FOP 2.0, is there a plan to release a bug fix release for 1.1? For example, we may be specifically interested in getting a new release with this issue resolved: https://issues.apache.org/jira/browse/FOP-2157 (in the ticket I have attached a fix for the same). Is there something we could do to support you in the process? Thank you, Jacopo
Question on FOP release schedule
Hi all, I am a committer for Apache OFBiz, a project that uses FOP 1.1 (thanks for this amazing product). I hope this is the right list to get some information about the release process and planning of Apache FOP. Apart from FOP 2.0, is there a plan to release a bug fix release for 1.1? For example, we may be specifically interested in getting a new release with this issue resolved: https://issues.apache.org/jira/browse/FOP-2157 (in the ticket I have attached a fix for the same). Is there something we could do to support you in the process? Thank you, Jacopo
Re: Question on FOP release schedule
I can apply your patch although I do not have the environment to test it. Regarding the question about a bug fix for 1.1, the answer is that there is nothing planned but if there is interest from the FOP users I think that can be accommodated. Is there any other bug your would like to see fixed in a 1.1+ release? On 10/2/14, 7:22 PM, Jacopo Cappellato wrote: Hi all, I am a committer for Apache OFBiz, a project that uses FOP 1.1 (thanks for this amazing product). I hope this is the right list to get some information about the release process and planning of Apache FOP. Apart from FOP 2.0, is there a plan to release a bug fix release for 1.1? For example, we may be specifically interested in getting a new release with this issue resolved: https://issues.apache.org/jira/browse/FOP-2157 (in the ticket I have attached a fix for the same). Is there something we could do to support you in the process? Thank you, Jacopo
Re: Question on FOP release schedule
Thank you Luis, I have attached to Jira a Junit test for the CompareUtil.equal method that should prove the issue we are facing and should confirm that the fix I am proposing should work ok. As regards the bug fix release, at the moment this is the only issue that I am aware of that is causing some pain to OFBiz and having a bug fix release for it would be great; however I know that the release workflow requires a good amount of work and I am wondering if I or other OFBiz committers may be of any help in the release process (e.g. we could help the FOP community to maintain a release branch for 1.1 by backporting fixes to it and testing it). I am wide open to any suggestions. Of course OFBiz will upgrade to the new release 2.0 as soon as this will be available and we will help you to test that as well. All in all I am just trying to give something back to the FOP community, since the OFBiz community has been a rather silent and passive user of your amazing tool :-) Regards, Jacopo On Oct 3, 2014, at 1:15 AM, Luis Bernardo lmpmberna...@gmail.com wrote: I can apply your patch although I do not have the environment to test it. Regarding the question about a bug fix for 1.1, the answer is that there is nothing planned but if there is interest from the FOP users I think that can be accommodated. Is there any other bug your would like to see fixed in a 1.1+ release? On 10/2/14, 7:22 PM, Jacopo Cappellato wrote: Hi all, I am a committer for Apache OFBiz, a project that uses FOP 1.1 (thanks for this amazing product). I hope this is the right list to get some information about the release process and planning of Apache FOP. Apart from FOP 2.0, is there a plan to release a bug fix release for 1.1? For example, we may be specifically interested in getting a new release with this issue resolved: https://issues.apache.org/jira/browse/FOP-2157 (in the ticket I have attached a fix for the same). Is there something we could do to support you in the process? Thank you, Jacopo
New FOP Release [was: Re: FOP Release Automation]
Hi, On 15/07/14 16:53, Clay Leeds wrote: On Jul 15, 2014, at 7:46 AM, Glenn Adams gl...@skynav.com wrote: I suppose it depends on whether or not we need to hack perl to use the facility. If there is any alternative that doesn't use perl, then that would be preferable. Frankly, I've never been happy with the new MD based documentation, though Clay has spent an inordinate amount of time tweaking it. Yeah... It's not my favorite either, but at least edits are pretty quick, saved to SVN and we've got a solution to incorporate javadoc, etc. In the meantime, please let me know when we're ready to update the documentation for the Release. It doesn't take me very long to go through the code to make these types of batch edits. snip/ Clay, your offer to help would be greatly appreciated! And since you’re mentioning it, maybe it’s time to think about making a new release of FOP. Although now that the font merging code has been merged to trunk, and introduces a dependency on FontBox 2.0.0, we would have to wait that FontBox 2.0.0 is released first. Or adapt the code to keep the former 1.8.5 dependency (or the newer 1.8.6 released version). In the meantime, can anybody think of features that should definitely be implemented before the release, or bugs fixed? Remember that due to API changes, that release will have to be called 2.0. Thanks, Vincent
RE: New FOP Release [was: Re: FOP Release Automation]
Hi, I switched fop back to fontbox 1.8, so its only the pdfplugin that uses 2.0 and the user would delete 1.8 jar if copying pdfplugin to fop. Thanks -Original Message- From: Vincent Hennebert [mailto:vhenneb...@gmail.com] Sent: 16 July 2014 12:56 To: fop-dev@xmlgraphics.apache.org Subject: New FOP Release [was: Re: FOP Release Automation] Hi, On 15/07/14 16:53, Clay Leeds wrote: On Jul 15, 2014, at 7:46 AM, Glenn Adams gl...@skynav.com wrote: I suppose it depends on whether or not we need to hack perl to use the facility. If there is any alternative that doesn't use perl, then that would be preferable. Frankly, I've never been happy with the new MD based documentation, though Clay has spent an inordinate amount of time tweaking it. Yeah... It's not my favorite either, but at least edits are pretty quick, saved to SVN and we've got a solution to incorporate javadoc, etc. In the meantime, please let me know when we're ready to update the documentation for the Release. It doesn't take me very long to go through the code to make these types of batch edits. snip/ Clay, your offer to help would be greatly appreciated! And since you’re mentioning it, maybe it’s time to think about making a new release of FOP. Although now that the font merging code has been merged to trunk, and introduces a dependency on FontBox 2.0.0, we would have to wait that FontBox 2.0.0 is released first. Or adapt the code to keep the former 1.8.5 dependency (or the newer 1.8.6 released version). In the meantime, can anybody think of features that should definitely be implemented before the release, or bugs fixed? Remember that due to API changes, that release will have to be called 2.0. Thanks, Vincent
Re: FOP Release Automation
I prefer python but bash is fine. OTOH, anything written by Larry Wall should be avoided like the plague. On Tue, Jul 15, 2014 at 8:53 AM, Clay Leeds the.webmaes...@gmail.com wrote: On Jul 15, 2014, at 7:46 AM, Glenn Adams gl...@skynav.com wrote: I suppose it depends on whether or not we need to hack perl to use the facility. If there is any alternative that doesn't use perl, then that would be preferable. Frankly, I've never been happy with the new MD based documentation, though Clay has spent an inordinate amount of time tweaking it. Yeah... It's not my favorite either, but at least edits are pretty quick, saved to SVN and we've got a solution to incorporate javadoc, etc. In the meantime, please let me know when we're ready to update the documentation for the Release. It doesn't take me very long to go through the code to make these types of batch edits. I'm good at this, and who knows, I might even spend the time to write some bash script to help us with the deployment! (you don't have anything against BASH, do ya Glenn?) :-p) (I think that's how to write a smiley with a tongue-in-cheek? :-D)
RE: FOP Release Automation
To use this utility it will require modification of our own Perl modules found on the FOP SVN site. Whether that requires just a change to the patterns (path.pm file) or the more complicated requirement of writing our own pattern subroutine (in the view.pm) I am not yet sure. Unfortunately though I'll have to park this as I currently have no more time I can spend on it but as I said will keep my eye on it and let you know if anything progresses. In the meantime I am guessing there will be a vote to release fairly soon which will result in the documentation needing to be updated. Subject: Re: FOP Release Automation From: the.webmaes...@gmail.com Date: Tue, 15 Jul 2014 07:53:19 -0700 To: fop-dev@xmlgraphics.apache.org On Jul 15, 2014, at 7:46 AM, Glenn Adams gl...@skynav.com wrote: I suppose it depends on whether or not we need to hack perl to use the facility. If there is any alternative that doesn't use perl, then that would be preferable. Frankly, I've never been happy with the new MD based documentation, though Clay has spent an inordinate amount of time tweaking it. Yeah... It's not my favorite either, but at least edits are pretty quick, saved to SVN and we've got a solution to incorporate javadoc, etc. In the meantime, please let me know when we're ready to update the documentation for the Release. It doesn't take me very long to go through the code to make these types of batch edits. I'm good at this, and who knows, I might even spend the time to write some bash script to help us with the deployment! (you don't have anything against BASH, do ya Glenn?) :-p) (I think that's how to write a smiley with a tongue-in-cheek? :-D)
Re: FOP Release Automation
Hi,
If we go to an svn:externals set in CMS repo, pointing to FOP trunk
doc, and 2 last FOP tagged doc, we should take care about having no
change in TAGs. Perhaps a pre-commit hook can do the job here, warning
the committer, or forbidding the commit propagation.
2014-05-30 23:34 GMT+02:00 Robert Meyer rme...@hotmail.co.uk:
I'll definitely look into those. I'm going to be away on holiday now for a
week or so but will continue once I get back.
Many thanks!
Robert
From: Clay Leeds
Sent: 5/30/2014 17:24
To: Apache FOP
Subject: Re: FOP Release Automation
Agreed, ‘some’ people wouldn’t be happy with that. ;-)
I wonder if the CMS Web interface could be extended to allow for a few
keywords like FOP_VERSION, FOP_REVISION, FOP_BRANCH, etc.
The CMS tool's WYSIWYG interface indicates it uses the Wysiwym MarkDown
Editor, which is extensible:
https://web.archive.org/web/20110121060932/http://wmd-editor.com/
(site’s down hasn’t been updated since 2011)...
or
https://code.google.com/p/wmd/
We might still need to do some ANT hanky panky, but at least if we could
leverage WMD’s extensibility it would help us get where we’re trying to go?
Clay
On May 30, 2014, at 7:19 AM, Robert Meyer rme...@hotmail.co.uk wrote:
Hi,
I like the simplicity of your idea, but the web interface is not so easy to
dismiss unfortunately.
If you do have a copy with those tags in, if any changes are made on the web
interface then that copy would become out of date.
We could always shutdown the web interface, but I don't think too many
people would be happy with that ;-)
Regards,
Robert
From: simonsteiner1...@gmail.com
To: fop-dev@xmlgraphics.apache.org
Subject: RE: FOP Release Automation
Date: Fri, 30 May 2014 14:48:15 +0100
Hi,
Simple way is to store docs inside fop repo:
Fop/docs/index.markdown
Inside markdown file you reference ant properties eg:
${version}
Then you call which does ant expandproperties and calls markdown to html
tool:
ant docs
Then you call which does a zip, scp and unzip of html files to web server:
ant upload-docs
This method doesn’t support web interface of editing files but I don’t see
how this is really needed.
If I submit a patch to fop it should also contain doc changes rather than
having separate repo and patch for that.
Thanks
From: Robert Meyer [mailto:rme...@hotmail.co.uk]
Sent: 30 May 2014 14:05
To: fop-dev@xmlgraphics.apache.org
Subject: RE: FOP Release Automation
Hi,
After investigating your suggestions Clay I have found that svn-hooks can't
be used for the purpose we require unfortunately as it may lead to problems
with how SVN operates and also may have some unexpected results with files
being committed. This is stated in the documentation under Creating
Repository Hooks highlighted in the warning red box further down:
http://www-inst.eecs.berkeley.edu/~cs61b/fa09/docs/svn-book-html-chunk/svn.reposadmin.create.html
Pascal, I agree that the process is fairly straightforward, but I have been
asked to automate this further so am just looking into ideas presently.
I think a possible way forward then would be to use your suggestion Pascal
of placing the versioned docs for the site inside the FOP repository for
their associated version. These can then be referenced using the
svn-externals from the main site repository.
In addition to this, the main site files (which would need to be updated)
could contain tags for the last three versions which would be replaced using
Clay's markdown pre-processor suggestion. The pre-processor would replace
the tags with values stored in a properties file in the main site
repository.
To create a release, the user would need to update the svn-external
references to account for the new version and update the properties file for
tag replacement. When the properties file is pushed it will be read by the
custom markdown pre-processor and display the new version when rendered.
Those two stages could be done using a single script to simplify things
further, but the main complication is getting the markdown pre-processor
working. From looking at this page:
http://www.apache.org/dev/cmsref.html#markdown
I am guessing we use PyPy (Python Markdown) which supports extensions, so I
will look at this shortly to try out a small example and investigate the
feasibility of doing this. There is also the matter of updating the
versioned documents for each FOP when a new version is released, but maybe
this could be done with the pre-processor as well.
Anyway, let me know what you think.
Regards,
Robert
--
pascal
Re: FOP Release Automation
Hi All,
I certainly use the web interface when making small tweaks to the docs.
As you know users occasionally report small mistakes that require minor
tweaks. I'd like to streamline the updating of the website for release
purposes but I don't want to disable/prevent the current web
interface which works well when all you want to do is make a minor
adjustment in response to a user e-mail.
Rob is away this week, but he will continue the investigation into
scripting the website updates when he returns.
Thanks for the ideas so far, a few promising leads.
Thanks,
Chris
On 30/05/2014 17:23, Clay Leeds wrote:
Agreed, ‘some’ people wouldn’t be happy with that. ;-)
I wonder if the CMS Web interface could be extended to allow for a few
keywords like FOP_VERSION, FOP_REVISION, FOP_BRANCH, etc.
The CMS tool's WYSIWYG interface indicates it uses the Wysiwym
MarkDown Editor, which is extensible:
https://web.archive.org/web/20110121060932/http://wmd-editor.com/
(site’s down hasn’t been updated since 2011)...
or
https://code.google.com/p/wmd/
We might still need to do some ANT hanky panky, but at least if we
could leverage WMD’s extensibility it would help us get where we’re
trying to go?
Clay
On May 30, 2014, at 7:19 AM, Robert Meyer rme...@hotmail.co.uk
mailto:rme...@hotmail.co.uk wrote:
Hi,
I like the simplicity of your idea, but the web interface is not so
easy to dismiss unfortunately.
If you do have a copy with those tags in, if any changes are made on
the web interface then that copy would become out of date.
We could always shutdown the web interface, but I don't think too
many people would be happy with that ;-)
Regards,
Robert
From: simonsteiner1...@gmail.com mailto:simonsteiner1...@gmail.com
To: fop-dev@xmlgraphics.apache.org
mailto:fop-dev@xmlgraphics.apache.org
Subject: RE: FOP Release Automation
Date: Fri, 30 May 2014 14:48:15 +0100
Hi,
Simple way is to store docs inside fop repo:
Fop/docs/index.markdown
Inside markdown file you reference ant properties eg:
${version}
Then you call which does ant expandproperties and calls markdown to
html tool:
ant docs
Then you call which does a zip, scp and unzip of html files to web
server:
ant upload-docs
This method doesn’t support web interface of editing files but I
don’t see how this is really needed.
If I submit a patch to fop it should also contain doc changes rather
than having separate repo and patch for that.
Thanks
*From:*Robert Meyer [mailto:rme...@hotmail.co.uk]
*Sent:*30 May 2014 14:05
*To:*fop-dev@xmlgraphics.apache.org
mailto:fop-dev@xmlgraphics.apache.org
*Subject:*RE: FOP Release Automation
Hi,
After investigating your suggestions Clay I have found that svn-hooks
can't be used for the purpose we require unfortunately as it may lead
to problems with how SVN operates and also may have some unexpected
results with files being committed. This is stated in the
documentation under Creating Repository Hooks highlighted in the
warning red box further down:
http://www-inst.eecs.berkeley.edu/~cs61b/fa09/docs/svn-book-html-chunk/svn.reposadmin.create.html
http://www-inst.eecs.berkeley.edu/%7Ecs61b/fa09/docs/svn-book-html-chunk/svn.reposadmin.create.html
Pascal, I agree that the process is fairly straightforward, but I
have been asked to automate this further so am just looking into
ideas presently.
I think a possible way forward then would be to use your suggestion
Pascal of placing the versioned docs for the site inside the FOP
repository for their associated version. These can then be referenced
using the svn-externals from the main site repository.
In addition to this, the main site files (which would need to be
updated) could contain tags for the last three versions which would
be replaced using Clay's markdown pre-processor suggestion. The
pre-processor would replace the tags with values stored in a
properties file in the main site repository.
To create a release, the user would need to update the svn-external
references to account for the new version and update the properties
file for tag replacement. When the properties file is pushed it will
be read by the custom markdown pre-processor and display the new
version when rendered.
Those two stages could be done using a single script to simplify
things further, but the main complication is getting the markdown
pre-processor working. From looking at this page:
http://www.apache.org/dev/cmsref.html#markdown
I am guessing we use PyPy (Python Markdown) which supports
extensions, so I will look at this shortly to try out a small example
and investigate the feasibility of doing this. There is also the
matter of updating the versioned documents for each FOP when a new
version is released, but maybe this could be done with the
pre-processor as well.
Anyway, let me know what you think.
Regards,
Robert
RE: FOP Release Automation
Hi, After investigating your suggestions Clay I have found that svn-hooks can't be used for the purpose we require unfortunately as it may lead to problems with how SVN operates and also may have some unexpected results with files being committed. This is stated in the documentation under Creating Repository Hooks highlighted in the warning red box further down: http://www-inst.eecs.berkeley.edu/~cs61b/fa09/docs/svn-book-html-chunk/svn.reposadmin.create.html Pascal, I agree that the process is fairly straightforward, but I have been asked to automate this further so am just looking into ideas presently. I think a possible way forward then would be to use your suggestion Pascal of placing the versioned docs for the site inside the FOP repository for their associated version. These can then be referenced using the svn-externals from the main site repository. In addition to this, the main site files (which would need to be updated) could contain tags for the last three versions which would be replaced using Clay's markdown pre-processor suggestion. The pre-processor would replace the tags with values stored in a properties file in the main site repository. To create a release, the user would need to update the svn-external references to account for the new version and update the properties file for tag replacement. When the properties file is pushed it will be read by the custom markdown pre-processor and display the new version when rendered. Those two stages could be done using a single script to simplify things further, but the main complication is getting the markdown pre-processor working. From looking at this page: http://www.apache.org/dev/cmsref.html#markdown I am guessing we use PyPy (Python Markdown) which supports extensions, so I will look at this shortly to try out a small example and investigate the feasibility of doing this. There is also the matter of updating the versioned documents for each FOP when a new version is released, but maybe this could be done with the pre-processor as well. Anyway, let me know what you think. Regards, Robert
Re: FOP Release Automation
Agreed, ‘some’ people wouldn’t be happy with that. ;-)
I wonder if the CMS Web interface could be extended to allow for a few keywords
like FOP_VERSION, FOP_REVISION, FOP_BRANCH, etc.
The CMS tool's WYSIWYG interface indicates it uses the Wysiwym MarkDown Editor,
which is extensible:
https://web.archive.org/web/20110121060932/http://wmd-editor.com/
(site’s down hasn’t been updated since 2011)...
or
https://code.google.com/p/wmd/
We might still need to do some ANT hanky panky, but at least if we could
leverage WMD’s extensibility it would help us get where we’re trying to go?
Clay
On May 30, 2014, at 7:19 AM, Robert Meyer rme...@hotmail.co.uk wrote:
Hi,
I like the simplicity of your idea, but the web interface is not so easy to
dismiss unfortunately.
If you do have a copy with those tags in, if any changes are made on the web
interface then that copy would become out of date.
We could always shutdown the web interface, but I don't think too many people
would be happy with that ;-)
Regards,
Robert
From: simonsteiner1...@gmail.com
To: fop-dev@xmlgraphics.apache.org
Subject: RE: FOP Release Automation
Date: Fri, 30 May 2014 14:48:15 +0100
Hi,
Simple way is to store docs inside fop repo:
Fop/docs/index.markdown
Inside markdown file you reference ant properties eg:
${version}
Then you call which does ant expandproperties and calls markdown to html tool:
ant docs
Then you call which does a zip, scp and unzip of html files to web server:
ant upload-docs
This method doesn’t support web interface of editing files but I don’t see
how this is really needed.
If I submit a patch to fop it should also contain doc changes rather than
having separate repo and patch for that.
Thanks
From: Robert Meyer [mailto:rme...@hotmail.co.uk]
Sent: 30 May 2014 14:05
To: fop-dev@xmlgraphics.apache.org
Subject: RE: FOP Release Automation
Hi,
After investigating your suggestions Clay I have found that svn-hooks can't
be used for the purpose we require unfortunately as it may lead to problems
with how SVN operates and also may have some unexpected results with files
being committed. This is stated in the documentation under Creating
Repository Hooks highlighted in the warning red box further down:
http://www-inst.eecs.berkeley.edu/~cs61b/fa09/docs/svn-book-html-chunk/svn.reposadmin.create.html
Pascal, I agree that the process is fairly straightforward, but I have been
asked to automate this further so am just looking into ideas presently.
I think a possible way forward then would be to use your suggestion Pascal of
placing the versioned docs for the site inside the FOP repository for their
associated version. These can then be referenced using the svn-externals from
the main site repository.
In addition to this, the main site files (which would need to be updated)
could contain tags for the last three versions which would be replaced using
Clay's markdown pre-processor suggestion. The pre-processor would replace the
tags with values stored in a properties file in the main site repository.
To create a release, the user would need to update the svn-external
references to account for the new version and update the properties file for
tag replacement. When the properties file is pushed it will be read by the
custom markdown pre-processor and display the new version when rendered.
Those two stages could be done using a single script to simplify things
further, but the main complication is getting the markdown pre-processor
working. From looking at this page:
http://www.apache.org/dev/cmsref.html#markdown
I am guessing we use PyPy (Python Markdown) which supports extensions, so I
will look at this shortly to try out a small example and investigate the
feasibility of doing this. There is also the matter of updating the versioned
documents for each FOP when a new version is released, but maybe this could
be done with the pre-processor as well.
Anyway, let me know what you think.
Regards,
Robert
RE: FOP Release Automation
I'll definitely look into those. I'm going to be away on holiday now for a week
or so but will continue once I get back.
Many thanks!
Robert
From: Clay Leedsmailto:the.webmaes...@gmail.com
Sent: 5/30/2014 17:24
To: Apache FOPmailto:fop-dev@xmlgraphics.apache.org
Subject: Re: FOP Release Automation
Agreed, ‘some’ people wouldn’t be happy with that. ;-)
I wonder if the CMS Web interface could be extended to allow for a few keywords
like FOP_VERSION, FOP_REVISION, FOP_BRANCH, etc.
The CMS tool's WYSIWYG interface indicates it uses the Wysiwym MarkDown Editor,
which is extensible:
https://web.archive.org/web/20110121060932/http://wmd-editor.com/
(site’s down hasn’t been updated since 2011)...
or
https://code.google.com/p/wmd/
We might still need to do some ANT hanky panky, but at least if we could
leverage WMD’s extensibility it would help us get where we’re trying to go?
Clay
On May 30, 2014, at 7:19 AM, Robert Meyer rme...@hotmail.co.uk wrote:
Hi,
I like the simplicity of your idea, but the web interface is not so easy to
dismiss unfortunately.
If you do have a copy with those tags in, if any changes are made on the web
interface then that copy would become out of date.
We could always shutdown the web interface, but I don't think too many people
would be happy with that ;-)
Regards,
Robert
From: simonsteiner1...@gmail.com
To: fop-dev@xmlgraphics.apache.org
Subject: RE: FOP Release Automation
Date: Fri, 30 May 2014 14:48:15 +0100
Hi,
Simple way is to store docs inside fop repo:
Fop/docs/index.markdown
Inside markdown file you reference ant properties eg:
${version}
Then you call which does ant expandproperties and calls markdown to html tool:
ant docs
Then you call which does a zip, scp and unzip of html files to web server:
ant upload-docs
This method doesn’t support web interface of editing files but I don’t see
how this is really needed.
If I submit a patch to fop it should also contain doc changes rather than
having separate repo and patch for that.
Thanks
From: Robert Meyer [mailto:rme...@hotmail.co.uk]
Sent: 30 May 2014 14:05
To: fop-dev@xmlgraphics.apache.org
Subject: RE: FOP Release Automation
Hi,
After investigating your suggestions Clay I have found that svn-hooks can't
be used for the purpose we require unfortunately as it may lead to problems
with how SVN operates and also may have some unexpected results with files
being committed. This is stated in the documentation under Creating
Repository Hooks highlighted in the warning red box further down:
http://www-inst.eecs.berkeley.edu/~cs61b/fa09/docs/svn-book-html-chunk/svn.reposadmin.create.html
Pascal, I agree that the process is fairly straightforward, but I have been
asked to automate this further so am just looking into ideas presently.
I think a possible way forward then would be to use your suggestion Pascal of
placing the versioned docs for the site inside the FOP repository for their
associated version. These can then be referenced using the svn-externals from
the main site repository.
In addition to this, the main site files (which would need to be updated)
could contain tags for the last three versions which would be replaced using
Clay's markdown pre-processor suggestion. The pre-processor would replace the
tags with values stored in a properties file in the main site repository.
To create a release, the user would need to update the svn-external
references to account for the new version and update the properties file for
tag replacement. When the properties file is pushed it will be read by the
custom markdown pre-processor and display the new version when rendered.
Those two stages could be done using a single script to simplify things
further, but the main complication is getting the markdown pre-processor
working. From looking at this page:
http://www.apache.org/dev/cmsref.html#markdown
I am guessing we use PyPy (Python Markdown) which supports extensions, so I
will look at this shortly to try out a small example and investigate the
feasibility of doing this. There is also the matter of updating the versioned
documents for each FOP when a new version is released, but maybe this could
be done with the pre-processor as well.
Anyway, let me know what you think.
Regards,
Robert
Re: FOP Release Automation
Hi, I didn't remember that I've rewritten the release page [1] (only refactor, no content change except website update). So, reading it back can figure how simple such task should be. Comments? [1] http://xmlgraphics.apache.org/fop/dev/release.html#cms 2014-05-28 10:57 GMT+02:00 Robert Meyer rme...@hotmail.co.uk: Hi Clay and Pascal, Sorry for my late reply with this. Pascal your idea makes a lot of sense as that will keep all versioned docs with their associated FOP version. I haven't had much of a chance to look at this over the last couple of days but am planning on spending some time in the coming days. Clay, both of what you mention sound intriguing so I'll take a look at those. I think updating it manually will be a last resort as even just writing an ant script would be preferable! If it does come to a script, the idea of copying the trunk folder and doing a find / replace on say trunk and replacing with 2.0 would be an option (with some caveats), but I'll investigate the other methods first. I'll keep you posted. Regards, Robert Meyer Subject: Re: FOP Release Automation From: the.webmaes...@gmail.com Date: Tue, 27 May 2014 21:33:32 -0700 To: fop-dev@xmlgraphics.apache.org Hi, I thought I'd give an update on my research of speeding the RELEASE process... I've spent some time researching, and I've asked for some assistance from site-dev@... Among the ideas I've been researching are: - MarkDown PreProcessor[1] - svn hook I'm not married to either of these solutions, but they look interesting. Of course, another idea, is to do it the OLD way, and I'd be happy to go through and update the MarkDown files with the latest/updated version. MarkDown PreProcessor (a sample I thought was interesting) [1] http://aaronparecki.com/articles/2012/09/01/1/some-enhancements-to-markdown More inline... On May 23, 2014, at 1:00 AM, Pascal Sancho psancho@gmail.com wrote: Hi, The FOP package should not embed the whole website, but only the documentation part, more precisely only the relevant version folder. Currently, FOP doc folder is referenced as svn:externals in FOP repo, resulting on extra irrelevant info, such as other versions, miscellaneous processes, general info, etc. IMHO, FOP versionned doc should be in FOP repo, and Website repo should refer to each FOP versionned doc through svn:externals prop. WDYT? +1 Pascal... Makes sense to me. There's a lot of cruft in there... We'd have to either `svn:externals` a bunch of single files (svn-1.7+), or adjust the site a bit to move the OLD versions somewhere 'out of the way'... (And then add 301 redirects... ;-) Cheers! Clay Leeds @ the.webmaes...@gmail.com My religion is simple. My religion is kindness. HH the Dalai Lama of Tibet -- pascal
Re: FOP Release Automation
Hi, The FOP package should not embed the whole website, but only the documentation part, more precisely only the relevant version folder. Currently, FOP doc folder is referenced as svn:externals in FOP repo, resulting on extra irrelevant info, such as other versions, miscellaneous processes, general info, etc. IMHO, FOP versionned doc should be in FOP repo, and Website repo should refer to each FOP versionned doc through svn:externals prop. WDYT? 2014-05-23 5:15 GMT+02:00 Clay Leeds the.webmaes...@gmail.com: Thank you for looking at this, Robert. I'll take a look at MarkDown solutions as well. Cheers! Clay -- My religion is simple. My religion is kindness. - HH The Dalai Lama of Tibet On May 21, 2014, at 2:24 AM, Robert Meyer rme...@hotmail.co.uk wrote: Hi All, I've been asked to look at a way to automate the FOP release process with regards the website documentation. At the moment every new release requires the following: 1) Download the site from SVN 2) Copy the folder containing the latest version's markdown files (1.1 for example) and rename to the new version 3) Go through all the files manually and update all the references from the old to the new version 4) Update any markdown files in the main directory with regard to the current and previous versions. 5) Delete the oldest version folder as we need only mantain the last 3. 6) Check and resubmit all files back to SVN My initial thought would to have a master copy in a separate directory. That copy would contain a tag in place where the version is given which could be substituted by a script of some kind (ant has a facility to do this). The ant script would also perform all of the above tasks so the only thing left to the user will be to check the output and push the new files. The problem I have with this is that SVN is not the only way in which the files can be edited as there is the web interface. If someone were to edit the files from there, the master copies would become out of date and worse, if someone were to perform a release it would overwrite all those changes. I've been recommended to look at markdown extensions but if anyone else has any ideas on the best way to go about this it would be much appreciated. Thanks, Robert Meyer -- pascal
Re: FOP Release Automation
Thank you for looking at this, Robert. I'll take a look at MarkDown solutions as well. Cheers! Clay -- My religion is simple. My religion is kindness. - HH The Dalai Lama of Tibet On May 21, 2014, at 2:24 AM, Robert Meyer rme...@hotmail.co.uk wrote: Hi All, I've been asked to look at a way to automate the FOP release process with regards the website documentation. At the moment every new release requires the following: 1) Download the site from SVN 2) Copy the folder containing the latest version's markdown files (1.1 for example) and rename to the new version 3) Go through all the files manually and update all the references from the old to the new version 4) Update any markdown files in the main directory with regard to the current and previous versions. 5) Delete the oldest version folder as we need only mantain the last 3. 6) Check and resubmit all files back to SVN My initial thought would to have a master copy in a separate directory. That copy would contain a tag in place where the version is given which could be substituted by a script of some kind (ant has a facility to do this). The ant script would also perform all of the above tasks so the only thing left to the user will be to check the output and push the new files. The problem I have with this is that SVN is not the only way in which the files can be edited as there is the web interface. If someone were to edit the files from there, the master copies would become out of date and worse, if someone were to perform a release it would overwrite all those changes. I've been recommended to look at markdown extensions but if anyone else has any ideas on the best way to go about this it would be much appreciated. Thanks, Robert Meyer
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
Fop release 1.0 in the press
I found three news items about FOP 1.0 release: - http://www.h-online.com/open/news/item/Apache-FOP-gets-a-1-0-release-1042748.html - http://www.heise.de/newsticker/meldung/FOP-1-0-XML-fast-beliebig-drucken-1043077.html - http://java.dzone.com/news/fop-10-rounds-out-apache-xml?utm_source=feedburnerutm_medium=feedutm_campaign=Feed%3A+zones%2Fcss+%28CSS+Zone%29 All three made up their own texts, picking from the press release and adding other information. Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: Updating the FOP release plan
Looks like there won't be any more voices. The majority seems to favor a 1.0 release. That's fine by me as long as we can break the 0.x curse. I'm surprised and grateful that we can finally move forward version-number-wise. I think we'll need to announce that release (codename Curse Breaker ;-)) carefully so people don't suddenly assume we have a 100% implementation of XSL 1.0 or something. I think it'll make sense to work with the PRC to do this right. After all, this particular release will create its ripples even if on a technical level the jump isn't that big. So my proposal would be to work towards a beta release early next year. By then the AFP and newIF branches should be merged with trunk. Hopefully it shouldn't take us another half year to release the final 1.0 after the beta. The previous beta-phase was really much too long. On 19.11.2008 09:37:41 Jeremias Maerki wrote: On a serious note (as opposed to my outburst on fop-users), I think we should really discuss the FOP release plan which we haven't updated in a while. I would hate to see FOP in 0.x mode after 10 years of existence. Let's assume 0.20.5 was actually FOP 1.0, and FOP 0.95 was actually FOP 2.0. How about calling the next version 2.009 (to be released in early 2009). Skip 1.0 entirely since that would only let the expectations rise into the sky. FOP had a major redesign which warrants at least a version jump of one major version. Not calling it 2.0 means it's not a first release from a fresh development branch. That will carry the message along that FOP is stable and usable in a productive environment. Hell, it's used in production by so many people for so many years. OhpointXitis is really bad. I know we still have about one item left on our pre-1.0 list: http://wiki.apache.org/xmlgraphics-fop/ReleasePlanning But that's still going to take a while. I want to revisit this list and see what today's view is. Flame away. Jeremias Maerki Jeremias Maerki
Re: Updating the FOP release plan
Hi, My actual opinion is not politically correct, so I’ll try to stick to constructive comments. Jeremias Maerki wrote: On a serious note (as opposed to my outburst on fop-users), I think we should really discuss the FOP release plan which we haven't updated in a while. I would hate to see FOP in 0.x mode after 10 years of existence. Let's assume 0.20.5 was actually FOP 1.0, and FOP 0.95 was actually FOP 2.0. Seen from today’s point of view, I very much agree with that. Actually the first release from the re-design branch (0.90 alpha 1) should have been called 1.0alpha, 0.91beta should have been called 1.0beta, 0.92beta 1.0RC and 0.93 1.0, or something like that. How about calling the next version 2.009 (to be released in early 2009). Hmmm... no. Too many digits after the dot IMO, and not meaningful enough. If we were to release another version in, say, September, how would we call it? When the year is used in the versioning scheme, it’s usually in the form of year.month (Ubuntu, AMD Catalyst drivers, etc.). Moreover, it can only puzzle users I think. We’ve used 1.0 version numbers for all those years, we’ve started a whole series of 0.9x releases, and all of a sudden we jump to 2.0?! With no significant changes from 0.95, moreover. They will wonder what is that revolution that they missed and that justifies such a jump. The ‘least worse’ way to stop the 1.0 curse, IMO, is to actually call the next release 1.0, with the following message: the re-design branch has been worked on for quite some time now, it brings many new features and improvements compared to the old 0.20.5; it’s considered stable enough to be used in production and 1.0 is used to acknowledge that. The work on changing IPD is likely to bring major changes to the layout engine, which will justify a 1.5 or 2.0 version. Once serious work has been done on optimization, a 2.5 or 3.0 can be released. Once significant features from XSL-FO 1.1 have been added, 3.5 or 4.0. And so on. After all, there are many open-source projects that have been around for years, and whose version numbers are still in 1.x or 2.x.x. Skip 1.0 entirely since that would only let the expectations rise into the sky. FOP had a major redesign which warrants at least a version jump of one major version. Not calling it 2.0 means it's not a first release from a fresh development branch. That will carry the message along that FOP is stable and usable in a productive environment. Hell, it's used in production by so many people for so many years. OhpointXitis is really bad. I know we still have about one item left on our pre-1.0 list: http://wiki.apache.org/xmlgraphics-fop/ReleasePlanning But that's still going to take a while. I want to revisit this list and see what today's view is. Flame away. Jeremias Maerki Vincent
Re: Updating the FOP release plan
1.0 sounds fine to me, 2.009 seems like a bit of a jump from 0.95 :). Adrian. The Web Maestro wrote: On Thu, Nov 20, 2008 at 5:11 AM, Vincent Hennebert [EMAIL PROTECTED] wrote: snip/ Moreover, it can only puzzle users I think. We've used 1.0 version numbers for all those years, we've started a whole series of 0.9x releases, and all of a sudden we jump to 2.0?! With no significant changes from 0.95, moreover. They will wonder what is that revolution that they missed and that justifies such a jump. I agree with Vincent here. I'd like to finally see a 1.0 release... Perhaps we'll be in the minority of having a stable 1.0 release (or at least that's the hope!)? ;-) The 'least worse' way to stop the 1.0 curse, IMO, is to actually call the next release 1.0, with the following message: the re-design branch has been worked on for quite some time now, it brings many new features and improvements compared to the old 0.20.5; it's considered stable enough to be used in production and 1.0 is used to acknowledge that. The work on changing IPD is likely to bring major changes to the layout engine, which will justify a 1.5 or 2.0 version. Once serious work has been done on optimization, a 2.5 or 3.0 can be released. Once significant features from XSL-FO 1.1 have been added, 3.5 or 4.0. And so on. After all, there are many open-source projects that have been around for years, and whose version numbers are still in 1.x or 2.x.x. IMHO, we should finally get out of the crib, and call it fop-1.0. Regards, The Web Maestro
Re: Updating the FOP release plan
Il giorno 19/nov/08, alle ore 09:37, Jeremias Maerki ha scritto:
How about calling the next version 2.009 (to be released in early
2009).
joking
You may choose to compose a strange number like Knuth is doing with $
\pi$ for \TeX versioning. What about $\sqrt{2}$? :P
/joking
Re: Updating the FOP release plan
Sorry to mingle into this, but even if releasing a 1.0 is important (and
IMHO it should be done with current crop as it is recognized as stable for
it), a more important thing would be to update the empty space that appears
on the future...
I do believe that most current users and prospective users would like to see
what is in the road ahead... [i would hehehe]
;)
[no vote due to, well... i'm more a user then a dev of FOP hehehe]
On Thu, Nov 20, 2008 at 4:29 PM, Dario Laera [EMAIL PROTECTED] wrote:
Il giorno 19/nov/08, alle ore 09:37, Jeremias Maerki ha scritto:
How about calling the next version 2.009 (to be released in early
2009).
joking
You may choose to compose a strange number like Knuth is doing with $\pi$
for \TeX versioning. What about $\sqrt{2}$? :P
/joking
Re: Updating the FOP release plan
On 20 Nov 2008, at 17:29, Dario Laera wrote:
Il giorno 19/nov/08, alle ore 09:37, Jeremias Maerki ha scritto:
How about calling the next version 2.009 (to be released in early
2009).
joking
You may choose to compose a strange number like Knuth is doing with $
\pi$ for \TeX versioning. What about $\sqrt{2}$? :P
/joking
Now there's an idea... Doing something with Euler's famous formula,
perhaps:
\$-(e^(i*pi))\$ (=1.0) :-)
Just sticking to an 'ordinary' version number seems to dull anyway. I
don't mind if anyone is confused, quite on the contrary.
Cheers
Andreas
Re: Updating the FOP release plan
Come on, guys, this is a serious topic.
Andreas Delmelle wrote:
On 20 Nov 2008, at 17:29, Dario Laera wrote:
Il giorno 19/nov/08, alle ore 09:37, Jeremias Maerki ha scritto:
How about calling the next version 2.009 (to be released in early
2009).
joking
You may choose to compose a strange number like Knuth is doing with
$\pi$ for \TeX versioning. What about $\sqrt{2}$? :P
/joking
Now there's an idea... Doing something with Euler's famous formula,
perhaps:
\$-(e^(i*pi))\$ (=1.0) :-)
Just sticking to an 'ordinary' version number seems to dull anyway. I
don't mind if anyone is confused, quite on the contrary.
The least we can do is to use the golden number [1]:
(1 + sqrt(5))/2 ≈ 1.6180339887
Incidentally this number has been used in book design for many years
[2]. Actually...
[1] http://en.wikipedia.org/wiki/Golden_ratio
[2] http://en.wikipedia.org/wiki/Golden_ratio#Book_design
Vincent
Re: Updating the FOP release plan
On 20 Nov 2008, at 18:55, Vincent Hennebert wrote: Come on, guys, this is a serious topic. Oops... I'd better withdraw from the discussion, then. ;-) BTW: 'FOP phi' (golden ratio) does have a nice ring to it. Cheers Andreas
Re: Updating the FOP release plan
Thanx ;)
I do believe that the plan called for a 3 months of beta before making
it version 1...
The last release was 0.95... in August... and not beta...
So, my only question is... if this release isn't version 1, then, what
is missing that you all feel it should be included/corrected? (that plan
pre-dates 2005)
Make the list, work on it... and release the next version...
And you can call it the Cloud Document Generator, after all, seams to
exist a new crazy around the computer wannabes (meaning marketeers of
IT) to call everything new Cloud (Cloud FOP?)
Because, from my point of view, and my tests with it, its more then
ready... hehehe
;)
Jeremias Maerki wrote:
Luis,
feedback from users is very welcome. Always. So no need to apologize.
If you want to know what we're working on (long-term), take a look at
http://wiki.apache.org/xmlgraphics-fop/RoadMap. Some of us note our
priorities there. Of course, there are always smaller short-term tasks
(bugs and new features) that pop up on short notice and get done as
quickly. http://xmlgraphics.apache.org/fop/changes.html tells you what
has been worked on in Trunk.
On 20.11.2008 17:52:49 Luis Ferro wrote:
Sorry to mingle into this, but even if releasing a 1.0 is important (and
IMHO it should be done with current crop as it is recognized as stable for
it), a more important thing would be to update the empty space that appears
on the future...
I do believe that most current users and prospective users would like to see
what is in the road ahead... [i would hehehe]
;)
[no vote due to, well... i'm more a user then a dev of FOP hehehe]
On Thu, Nov 20, 2008 at 4:29 PM, Dario Laera [EMAIL PROTECTED] wrote:
Il giorno 19/nov/08, alle ore 09:37, Jeremias Maerki ha scritto:
How about calling the next version 2.009 (to be released in early
2009).
joking
You may choose to compose a strange number like Knuth is doing with $\pi$
for \TeX versioning. What about $\sqrt{2}$? :P
/joking
Jeremias Maerki
Updating the FOP release plan
On a serious note (as opposed to my outburst on fop-users), I think we should really discuss the FOP release plan which we haven't updated in a while. I would hate to see FOP in 0.x mode after 10 years of existence. Let's assume 0.20.5 was actually FOP 1.0, and FOP 0.95 was actually FOP 2.0. How about calling the next version 2.009 (to be released in early 2009). Skip 1.0 entirely since that would only let the expectations rise into the sky. FOP had a major redesign which warrants at least a version jump of one major version. Not calling it 2.0 means it's not a first release from a fresh development branch. That will carry the message along that FOP is stable and usable in a productive environment. Hell, it's used in production by so many people for so many years. OhpointXitis is really bad. I know we still have about one item left on our pre-1.0 list: http://wiki.apache.org/xmlgraphics-fop/ReleasePlanning But that's still going to take a while. I want to revisit this list and see what today's view is. Flame away. Jeremias Maerki
Re: Updating the FOP release plan
On 19 Nov 2008, at 09:37, Jeremias Maerki wrote: snip / How about calling the next version 2.009 (to be released in early 2009). I like this idea. Something different that shows a clear break with the past, and at the same time not too seriously... +1 snip / OhpointXitis is really bad. Agreed. We should finally move away from that. Cheers Andreas
Suport For Saxon in future FOP release
Hi, I noticed that during the ant build of the trunk, Saxon is used. Since Saxon is an xslt 2.0 processor, is there any plans to replace Xalan with Saxon as the default processor with future releases of FOP? Thanks, Phil -- View this message in context: http://www.nabble.com/Suport-For-Saxon-in-future-FOP-release-tp19329624p19329624.html Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Suport For Saxon in future FOP release
No. At runtime, FOP doesn't care what XSLT processor is used as long as it's JAXP compatible. Inside the test code there's a hard reference to Xalan for XPath processing. But that's unrelated to XSLT in general. The runtime code doesn't have a dependency on Xalan. On 05.09.2008 13:53:16 Philip V wrote: Hi, I noticed that during the ant build of the trunk, Saxon is used. Since Saxon is an xslt 2.0 processor, is there any plans to replace Xalan with Saxon as the default processor with future releases of FOP? Thanks, Phil -- View this message in context: http://www.nabble.com/Suport-For-Saxon-in-future-FOP-release-tp19329624p19329624.html Sent from the FOP - Dev mailing list archive at Nabble.com. Jeremias Maerki
Re: Suport For Saxon in future FOP release
One could potentially have a code path using the latest JAXP XPath facilities to avoid requiring Saxon... Of course XPath is a bit funny. Saxon's XPath does not return live nodes from the original DOM you hand to it. Xalan's does -- but ever since 2.1.0 has assumed that you're going to do a lot of XPath against each DOM without any changes. Thus ever since 2.1.0 Xalan has been incapable of any reasonable performance on a frequently changing, infrequently XPath'ed DOM (e.g. where you're using XPath to select DOM nodes and then modify them). Jaxen and JXPath were flakey as could be for real world XPaths (giving incorrect results in many critical cases) and didn't have JAXP compliant XPath APIs last I investigated. XSLT is simpler -- Saxon currently rules. XSLT 1.0 is too limiting to justify continued use of Xalan. -- Jess Holle Jeremias Maerki wrote: No. At runtime, FOP doesn't care what XSLT processor is used as long as it's JAXP compatible. Inside the test code there's a hard reference to Xalan for XPath processing. But that's unrelated to XSLT in general. The runtime code doesn't have a dependency on Xalan. On 05.09.2008 13:53:16 Philip V wrote: Hi, I noticed that during the ant build of the trunk, Saxon is used. Since Saxon is an xslt 2.0 processor, is there any plans to replace Xalan with Saxon as the default processor with future releases of FOP? Thanks, Phil -- View this message in context: http://www.nabble.com/Suport-For-Saxon-in-future-FOP-release-tp19329624p19329624.html Sent from the FOP - Dev mailing list archive at Nabble.com. Jeremias Maerki
Re: New FOP release: FOP 0.93
On Tue, Dec 19, 2006 at 09:02:06PM +0100, Simon Pepping wrote: As discussed recently, I will prepare a release of FOP, to be named 0.93. I have committed fixes for the reported issues with the dist files. I have also fixed a few other issues I discovered. I have added a few important changes to the release note, and I have reset the target release date to 9 January 2007. I have tested the generated source and bin dist files. I could rebuild the dist target from the source dist. I have run the junit tests on the bin dist, after some fiddling with the targets in the Ant build file. I got one failure: [junit] Testcase: color_1.xml(org.apache.fop.layoutengine.LayoutEngineTestSuite$1): Caused an ERROR [junit] Expected XPath expression to evaluate to 'fop-rgb-icc(1.0,0.5,0.0,sRGB,../../../src/java/org/apache/fop/pdf/sRGB Color Space Profile.icm,1.0,0.5,0.0)', but got '#ff8000' (XPath: //block[4]//text/@color) which may be due to its dependence on a file in the src directory, which is not included in the bin dist. Please, test the current state of the branch xmlgraphics/fop/branches/fop-0_93 as a release candidate. See the commit message for the exact changes w.r.t. the rejected release. For your convenience I have uploaded one source dist file and one bin dist file, see http://people.apache.org/~spepping/. I intend to generate the dist files and start a vote on the release somewhere mid next week. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: New FOP release: FOP 0.93
Simon Pepping a écrit : On Tue, Dec 19, 2006 at 09:02:06PM +0100, Simon Pepping wrote: As discussed recently, I will prepare a release of FOP, to be named 0.93. I have committed fixes for the reported issues with the dist files. I have also fixed a few other issues I discovered. I have added a few important changes to the release note, and I have reset the target release date to 9 January 2007. I have tested the generated source and bin dist files. I could rebuild the dist target from the source dist. I have run the junit tests on the bin dist, after some fiddling with the targets in the Ant build file. I got one failure: [junit] Testcase: color_1.xml(org.apache.fop.layoutengine.LayoutEngineTestSuite$1): Caused an ERROR [junit] Expected XPath expression to evaluate to 'fop-rgb-icc(1.0,0.5,0.0,sRGB,../../../src/java/org/apache/fop/pdf/sRGB Color Space Profile.icm,1.0,0.5,0.0)', but got '#ff8000' (XPath: //block[4]//text/@color) which may be due to its dependence on a file in the src directory, which is not included in the bin dist. Please, test the current state of the branch xmlgraphics/fop/branches/fop-0_93 as a release candidate. See the commit message for the exact changes w.r.t. the rejected release. For your convenience I have uploaded one source dist file and one bin dist file, see http://people.apache.org/~spepping/. Hmmm, I was planning to work a bit on Fop during holidays, but obviously I haven't found the time... I'll get back to work on the release from next Tuesday on. Too bad, that fop.bat problem. But well, such problems always appear in computer science. Thanks for your great work for the release, anyway. Vincent
Re: New FOP release: FOP 0.93
Is there any sort of time table for a non-alpha/beta 0.9x or 1.0 release? -- Jess Holle
Re: New FOP release: FOP 0.93
On Sun, Dec 24, 2006 at 10:09:14AM -0600, Jess Holle wrote: Is there any sort of time table for a non-alpha/beta 0.9x or 1.0 release? That is what I am preparing: FOP 0.93 (without beta), to be released on 2 January 2007. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: New FOP release: FOP 0.93
Done, and branch xmlgraphics/fop/branches/fop-0_93 created. On Tue, Dec 19, 2006 at 09:02:06PM +0100, Simon Pepping wrote: As discussed recently, I will prepare a release of FOP, to be named 0.93. Two issues need to be addressed: 1. I will apply two patches by Richard Wheeldon, to improve memory usage: Bug http://issues.apache.org/bugzilla/show_bug.cgi?id=41009, with patch http://issues.apache.org/bugzilla/attachment.cgi?id=19177 en bug http://issues.apache.org/bugzilla/show_bug.cgi?id=41044, with patch http://issues.apache.org/bugzilla/attachment.cgi?id=19155. I will have to study the first patch, as I have not looked at it, and the bugzilla page contains nobody's comments. I will only apply the patch if it seems certain that it breaks nothing. I have studied and commented the second patch, as has Andreas, and I believe it can be safely applied before the release. Applying these patches allows us to present a production version whose memory usage has been trimmed somewhat. Applied both. 2. With this release it is possible to use the original font metrics, without generating a special metrics file for FOP. See http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200611.mbox/[EMAIL PROTECTED] There is no entry for this in the changes file, and there is no documentation on the website. It is important enough to clarify with the release. I will try to add some text to the changes file and perhaps something to the documentation. As I am not familiar with this material, if someone else can do a better job, please do. Change was already in the status file (but not on the web site). Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: New FOP release: FOP 0.93
I created the documentation for version 0.93 (see src/documentation/content/xdocs/0.93) and edited it for the new release version. Please, check it. Especial attention is needed for the new release notes, src/documentation/content/xdocs/relnotes.xml, most of which still have to be written, the FAQ, src/documentation/content/xdocs/faq.xml, the main page of this release, src/documentation/content/xdocs/0.93/index.xml, and the upgrading page, src/documentation/content/xdocs/0.93/upgrading.xml. On Wed, Dec 20, 2006 at 10:24:25AM +0100, Simon Pepping wrote: Done, and branch xmlgraphics/fop/branches/fop-0_93 created. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: New FOP release: FOP 0.93
On 19.12.2006 21:02:06 Simon Pepping wrote: As discussed recently, I will prepare a release of FOP, to be named 0.93. Two issues need to be addressed: 1. I will apply two patches by Richard Wheeldon, to improve memory usage: Bug http://issues.apache.org/bugzilla/show_bug.cgi?id=41009, with patch http://issues.apache.org/bugzilla/attachment.cgi?id=19177 en bug http://issues.apache.org/bugzilla/show_bug.cgi?id=41044, with patch http://issues.apache.org/bugzilla/attachment.cgi?id=19155. I will have to study the first patch, as I have not looked at it, and the bugzilla page contains nobody's comments. I will only apply the patch if it seems certain that it breaks nothing. I have studied and commented the second patch, as has Andreas, and I believe it can be safely applied before the release. Applying these patches allows us to present a production version whose memory usage has been trimmed somewhat. Thanks for taking care of this. 2. With this release it is possible to use the original font metrics, without generating a special metrics file for FOP. See http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200611.mbox/[EMAIL PROTECTED] There is no entry for this in the changes file, and there is no documentation on the website. It is important enough to clarify with the release. I will try to add some text to the changes file and perhaps something to the documentation. As I am not familiar with this material, if someone else can do a better job, please do. Well, this is still sort of experimental. The old functionality is unchanged and stable. I'm not so sure about the part without the font metrics. There wasn't much feedback. If this is to be documented, I'd prefer if it is marked as experimental. After these changes I will create a branch. Manuel, can you hold your changes until the branch has been created? Please, let me know if you have different ideas. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.eu Jeremias Maerki
New FOP release: FOP 0.93
As discussed recently, I will prepare a release of FOP, to be named 0.93. Two issues need to be addressed: 1. I will apply two patches by Richard Wheeldon, to improve memory usage: Bug http://issues.apache.org/bugzilla/show_bug.cgi?id=41009, with patch http://issues.apache.org/bugzilla/attachment.cgi?id=19177 en bug http://issues.apache.org/bugzilla/show_bug.cgi?id=41044, with patch http://issues.apache.org/bugzilla/attachment.cgi?id=19155. I will have to study the first patch, as I have not looked at it, and the bugzilla page contains nobody's comments. I will only apply the patch if it seems certain that it breaks nothing. I have studied and commented the second patch, as has Andreas, and I believe it can be safely applied before the release. Applying these patches allows us to present a production version whose memory usage has been trimmed somewhat. 2. With this release it is possible to use the original font metrics, without generating a special metrics file for FOP. See http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200611.mbox/[EMAIL PROTECTED] There is no entry for this in the changes file, and there is no documentation on the website. It is important enough to clarify with the release. I will try to add some text to the changes file and perhaps something to the documentation. As I am not familiar with this material, if someone else can do a better job, please do. After these changes I will create a branch. Manuel, can you hold your changes until the branch has been created? Please, let me know if you have different ideas. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: New FOP release: FOP 0.93
On Wednesday 20 December 2006 05:02, Simon Pepping wrote: snip/ Manuel, can you hold your changes until the branch has been created? No problems, will wait until the branch is there. Regards, Simon Manuel
