Re: FOP94: BuildTest fails with Dispatcher
Ferdinand Soethe wrote: Since the dispatcher test is still breaking trunk, I have now fixed some of the problems with fo used in the dispatcher plugin. Further tests unfortunately become impossible because forrest crashed with the message Exception in thread main java.lang.OutOfMemoryError: Java heap space. If trunk remains broken, can we perhaps take the test involving the whiteboard plugin (dispatcher) out of the standarf build test? -0 on that, dispatcher is in use - even if it is whiteboard. I'd rather see the dispathcers progress into trunk helped rather than hindered. If there was active development on Dispatcher I'd be -1, but given that it has been sleepy for a while I think -0 is fairer. Ross
Re: FOP94: BuildTest fails with Dispatcher
Thorsten Scherler wrote: On Sun, 2008-02-17 at 09:49 +0100, Ferdinand Soethe wrote: The problem still remains that the plugins use two different properties system which forces the dispatcher to maintain some custom code (which it is a pity). So we ought to make the new property system the default in trunk - shouldn't be too hard it has been rigorously tested in a number of plugins. (NB I still don't want to hold up the FOP work because of this, dispatcher is in whiteboard so FOP should take preference - I know some people would prefer to see dispatcher take precedence, including me actually, but until it is a released resource we should not let it dictate development priorities) Ross
Re: Focus of org.apache.forrest.plugin.internal.xhtml2
Thorsten Scherler wrote: Hi all, what is the focus/status of org.apache.forrest.plugin.internal.xhtml2? It was an experiment by me that was not well accepted. Status is dead. Ross
Re: FOP94: BuildTest fails with Dispatcher
On Mon, 2008-02-18 at 08:48 +, Ross Gardler wrote: Ferdinand Soethe wrote: Since the dispatcher test is still breaking trunk, I have now fixed some of the problems with fo used in the dispatcher plugin. Further tests unfortunately become impossible because forrest crashed with the message Exception in thread main java.lang.OutOfMemoryError: Java heap space. If trunk remains broken, can we perhaps take the test involving the whiteboard plugin (dispatcher) out of the standarf build test? -0 on that, dispatcher is in use - even if it is whiteboard. I'd rather see the dispathcers progress into trunk helped rather than hindered. If there was active development on Dispatcher I'd be -1, but given that it has been sleepy for a while I think -0 is fairer. I am -1 on that (as can be seen on some commits last night ;)). I am trying hard to get a first version of the dispatcher out and gladly I can do some work ATM in working hours. Hopefully last nights has shown a way to reuse skin stylesheets in contracts. The key is to group functionality in separate stylesheets. Thanks to the lm we can reuse this pieces of code in our contracts. salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
Re: Decouple fo from skinconf (was Re: svn commit: r618400 )
On Thu, 2008-02-07 at 23:36 +, Ross Gardler wrote: ... Why are we using skinconf for core plugins? The only plugin that should use skinconf is a skin plugin (if it would exist)! I'm not against breaking the dependency. I'm only against doing it in 0.3 PDF plugin, released for Forrest 0.8, without warning or good reason. Hmm, does the new plugin work in 0.8? If so can we not release it now and after this raise the version to 0.4 which depends on 0.9. This would allow to incorporate the new properties system and get rid of duplicate code in the dispatcher. wdyt? salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
Re: Merge Fop94 now
On Mon, 2008-02-18 at 08:53 +, Ross Gardler wrote: Ferdinand Soethe wrote: I think we are ready to merge fop94 now. Several bugs in documents and stylesheets have been fixed. Build test for site-author and seed side passed without critical errors. The remaining problem of some broken images will not break trunk and probably requires some more input from the community. Build errors in the dispatcher still to be solved but since dispatcher is still in whiteboard this seems acceptable. wdyt? I'm not clear if these dispatcher errors are fixed or not, this mail is overlapping with that thread. In time of the merge the dispatcher was not fixed. If they are not fixed I am -1 on this merge as it will start a whole load of nag mails from the zone tests. I just saw last night the forrestbot reporting failure and fixed enough to get forrestbot doing its work again. Still some open issues to face. salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
Re: FOP94: BuildTest fails with Dispatcher
Thorsten Scherler wrote: On Mon, 2008-02-18 at 08:48 +, Ross Gardler wrote: Ferdinand Soethe wrote: Since the dispatcher test is still breaking trunk, I have now fixed some of the problems with fo used in the dispatcher plugin. Further tests unfortunately become impossible because forrest crashed with the message Exception in thread main java.lang.OutOfMemoryError: Java heap space. If trunk remains broken, can we perhaps take the test involving the whiteboard plugin (dispatcher) out of the standarf build test? -0 on that, dispatcher is in use - even if it is whiteboard. I'd rather see the dispathcers progress into trunk helped rather than hindered. If there was active development on Dispatcher I'd be -1, but given that it has been sleepy for a while I think -0 is fairer. I am -1 on that (as can be seen on some commits last night ;)). es, replied before I noticed your commits. I'm happy to support your -1. Ross
Re: Decouple fo from skinconf (was Re: svn commit: r618400 )
Thorsten Scherler wrote: On Thu, 2008-02-07 at 23:36 +, Ross Gardler wrote: ... Why are we using skinconf for core plugins? The only plugin that should use skinconf is a skin plugin (if it would exist)! I'm not against breaking the dependency. I'm only against doing it in 0.3 PDF plugin, released for Forrest 0.8, without warning or good reason. Hmm, does the new plugin work in 0.8? As I understand it, yes. If so can we not release it now and after this raise the version to 0.4 which depends on 0.9. This would allow to incorporate the new properties system and get rid of duplicate code in the dispatcher. wdyt? +1 - best of both worlds -good idea. Ross salu2
Re: Focus of org.apache.forrest.plugin.internal.xhtml2
On Mon, 2008-02-18 at 08:57 +, Ross Gardler wrote: Thorsten Scherler wrote: On Fri, 2008-02-15 at 13:49 +0100, Thorsten Scherler wrote: Hi all, what is the focus/status of org.apache.forrest.plugin.internal.xhtml2? In the XDocs plugin we do *-to-xhtml2 in the xhtml2 plugin I can find xhtml2-to-html. Does it makes sense to have as well xhtml2-to-document? These plugins were the start of a migration to an XHTML2 subset as internal format. The XDoc plugin was intended to convert from legacy formats to XHTML2 and the XHTML2 internal was the experimental replacement of XDoc on the inside. XHTML2-to-document would only make sense if we have input content in XHTML2 format. Actually the xdocs plugin is producing xhtml2, meaning using the combination would do the trick. That raises another question wouldn't we need to update all plugins to use xhtml2 as input instead of xdocs? salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
Re: Focus of org.apache.forrest.plugin.internal.xhtml2
Thorsten Scherler wrote: On Fri, 2008-02-15 at 13:49 +0100, Thorsten Scherler wrote: Hi all, what is the focus/status of org.apache.forrest.plugin.internal.xhtml2? In the XDocs plugin we do *-to-xhtml2 in the xhtml2 plugin I can find xhtml2-to-html. Does it makes sense to have as well xhtml2-to-document? These plugins were the start of a migration to an XHTML2 subset as internal format. The XDoc plugin was intended to convert from legacy formats to XHTML2 and the XHTML2 internal was the experimental replacement of XDoc on the inside. XHTML2-to-document would only make sense if we have input content in XHTML2 format. Ross
Re: Merge Fop94 now
Ferdinand Soethe wrote: I think we are ready to merge fop94 now. Several bugs in documents and stylesheets have been fixed. Build test for site-author and seed side passed without critical errors. The remaining problem of some broken images will not break trunk and probably requires some more input from the community. Build errors in the dispatcher still to be solved but since dispatcher is still in whiteboard this seems acceptable. wdyt? I'm not clear if these dispatcher errors are fixed or not, this mail is overlapping with that thread. If they are not fixed I am -1 on this merge as it will start a whole load of nag mails from the zone tests. Ross
Re: Focus of org.apache.forrest.plugin.internal.xhtml2
Thorsten Scherler wrote: On Mon, 2008-02-18 at 08:57 +, Ross Gardler wrote: Thorsten Scherler wrote: On Fri, 2008-02-15 at 13:49 +0100, Thorsten Scherler wrote: Hi all, what is the focus/status of org.apache.forrest.plugin.internal.xhtml2? In the XDocs plugin we do *-to-xhtml2 in the xhtml2 plugin I can find xhtml2-to-html. Does it makes sense to have as well xhtml2-to-document? These plugins were the start of a migration to an XHTML2 subset as internal format. The XDoc plugin was intended to convert from legacy formats to XHTML2 and the XHTML2 internal was the experimental replacement of XDoc on the inside. XHTML2-to-document would only make sense if we have input content in XHTML2 format. Actually the xdocs plugin is producing xhtml2, meaning using the combination would do the trick. That raises another question wouldn't we need to update all plugins to use xhtml2 as input instead of xdocs? Yes we would. That's one of the main reasons that the XHTML2 move has never actually happened, it's a very big job. Ross
Re: FOP94: BuildTest fails with Dispatcher
Great! Now we don't have to maintain two versions of this code. Thanks. Best regards, Ferdinand Soethe Thorsten Scherler wrote: On Sun, 2008-02-17 at 09:49 +0100, Ferdinand Soethe wrote: Since the dispatcher test is still breaking trunk, I have now fixed some of the problems with fo used in the dispatcher plugin. Further tests unfortunately become impossible because forrest crashed with the message Exception in thread main java.lang.OutOfMemoryError: Java heap space. I fixed this by capsulizing the xsl methods in different helper stylesheet which we can import from the different dispatcher contracts. This reduce the maintenance since we only maintain them in one place (the pdf plugin). The problem still remains that the plugins use two different properties system which forces the dispatcher to maintain some custom code (which it is a pity). There are still a lot of warnings I need to look into but it was getting too late last night and seeing forrest build successful I hit the bed. Next steps is to fix the remaining warnings in the dispatcher and move the dispatcher fo related resources to the pdf plugin as well. salu2
Re: Decouple fo from skinconf (was Re: svn commit: r618400 )
The pdf-plugin will not work with 0.8 as is because it was decided to move critical libs from the plugin back into core. Because of this, the plugin will only work with 0.8 if 0.8 gets patched. What I haven't tested so far is if 0.8 will work with a locally deployed plugin that is marked for 0.9? Or would somebody wanting to use the new plugin with 0.8 also have to patch the property name=forrest.version value=0.8/? Does anybody know or can anybody suggest a better solution? Best regards, Ferdinand Soethe Thorsten Scherler wrote: On Thu, 2008-02-07 at 23:36 +, Ross Gardler wrote: ... Why are we using skinconf for core plugins? The only plugin that should use skinconf is a skin plugin (if it would exist)! I'm not against breaking the dependency. I'm only against doing it in 0.3 PDF plugin, released for Forrest 0.8, without warning or good reason. Hmm, does the new plugin work in 0.8? If so can we not release it now and after this raise the version to 0.4 which depends on 0.9. This would allow to incorporate the new properties system and get rid of duplicate code in the dispatcher. wdyt? salu2
Re: Decouple fo from skinconf (was Re: svn commit: r618400 )
would it do any harm to deliver the libs twice? i.e. include in the 0.8 plugin (throw out for the later versions) and in core? I haven't had the time to test with 0.8, yet :-( Johannes Ferdinand Soethe schrieb: The pdf-plugin will not work with 0.8 as is because it was decided to move critical libs from the plugin back into core. Because of this, the plugin will only work with 0.8 if 0.8 gets patched. What I haven't tested so far is if 0.8 will work with a locally deployed plugin that is marked for 0.9? Or would somebody wanting to use the new plugin with 0.8 also have to patch the property name=forrest.version value=0.8/? Does anybody know or can anybody suggest a better solution? Best regards, Ferdinand Soethe Thorsten Scherler wrote: On Thu, 2008-02-07 at 23:36 +, Ross Gardler wrote: ... Why are we using skinconf for core plugins? The only plugin that should use skinconf is a skin plugin (if it would exist)! I'm not against breaking the dependency. I'm only against doing it in 0.3 PDF plugin, released for Forrest 0.8, without warning or good reason. Hmm, does the new plugin work in 0.8? If so can we not release it now and after this raise the version to 0.4 which depends on 0.9. This would allow to incorporate the new properties system and get rid of duplicate code in the dispatcher. wdyt? salu2 -- User Interface Design GmbH, Ludwigsburg (Germany) Phone/Fax +49 7141 37700-46/-99, Mobile +49 170 4914567 E-mail [EMAIL PROTECTED] * www.uidesign.de Offices: Martin-Luther-Straße 57-59, D-71636 Ludwigsburg Truderinger Strasse 330, D-81825 Muenchen Friedrichsring 46, D-68161 Mannheim Hansastraße 7-11, 44137 Dortmund Legal information according to EHUG: User Interface Design GmbH; Managing Directors: Dr. Claus Goerner, Franz Koller; Head office: Ludwigsburg; Commercial register of the local court of Stuttgart, Germany, HRB 205519 +++ UID auf der CeBit 2008: Erleben Sie User Experience Management! Stand A20 UX08 in Halle 9. http://www.uid.com/cebit2008 +++
Re: Decouple fo from skinconf (was Re: svn commit: r618400 )
It did not seem to do any harm when I first tested it with head. Even the duplicate libs caused no problems as far as I could tell. I agree, that might be a nice solution for 0.8 users and since we'd update the plugin to 0.9 dependant right away, it would really only be a short term solution. wdot? Best regards, Ferdinand Soethe Johannes Schaefer wrote: would it do any harm to deliver the libs twice? i.e. include in the 0.8 plugin (throw out for the later versions) and in core? I haven't had the time to test with 0.8, yet :-( Johannes Ferdinand Soethe schrieb: The pdf-plugin will not work with 0.8 as is because it was decided to move critical libs from the plugin back into core. Because of this, the plugin will only work with 0.8 if 0.8 gets patched. What I haven't tested so far is if 0.8 will work with a locally deployed plugin that is marked for 0.9? Or would somebody wanting to use the new plugin with 0.8 also have to patch the property name=forrest.version value=0.8/? Does anybody know or can anybody suggest a better solution? Best regards, Ferdinand Soethe Thorsten Scherler wrote: On Thu, 2008-02-07 at 23:36 +, Ross Gardler wrote: ... Why are we using skinconf for core plugins? The only plugin that should use skinconf is a skin plugin (if it would exist)! I'm not against breaking the dependency. I'm only against doing it in 0.3 PDF plugin, released for Forrest 0.8, without warning or good reason. Hmm, does the new plugin work in 0.8? If so can we not release it now and after this raise the version to 0.4 which depends on 0.9. This would allow to incorporate the new properties system and get rid of duplicate code in the dispatcher. wdyt? salu2
Please don't top post - (Re: Decouple fo from skinconf (was Re: svn commit: r618400 ))
Can we please avoid the increasing tendency to top-post. It loses the context of the email and makes it difficult to follow things in the archives (which is often our documentation). Ross
Re: Decouple fo from skinconf (was Re: svn commit: r618400 )
Ferdinand Soethe wrote: The pdf-plugin will not work with 0.8 as is because it was decided to move critical libs from the plugin back into core. I must have missed that. Why were they moved back in? What was the problem with moving them into the plugin? What I haven't tested so far is if 0.8 will work with a locally deployed plugin that is marked for 0.9? It won't (not tested, so I should say it shouldn't). Ross
Re: Please don't top post - (Re: Decouple fo from skinconf (was Re: svn commit: r618400 ))
don't know what you mean (see attachment: Thunderbird gets it right) and whom ... me?! might be Ferdinand, see below I believe this is not intentional, cheers Johannes Header bits --- Ross' former message: message-id= [EMAIL PROTECTED] Ferdinand's reply: message-id= [EMAIL PROTECTED] in-reply-to= [EMAIL PROTECTED]!? references= [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Ross' reply: in-reply-to= [EMAIL PROTECTED] my reply: in-reply-to= [EMAIL PROTECTED] message-id= [EMAIL PROTECTED] Ferdinand:in-reply-to= [EMAIL PROTECTED] lots of references as well Ross Gardler schrieb: Can we please avoid the increasing tendency to top-post. It loses the context of the email and makes it difficult to follow things in the archives (which is often our documentation). Ross -- User Interface Design GmbH, Ludwigsburg (Germany) Phone/Fax +49 7141 37700-46/-99, Mobile +49 170 4914567 E-mail [EMAIL PROTECTED] * www.uidesign.de Offices: Martin-Luther-Straße 57-59, D-71636 Ludwigsburg Truderinger Strasse 330, D-81825 Muenchen Friedrichsring 46, D-68161 Mannheim Hansastraße 7-11, 44137 Dortmund Legal information according to EHUG: User Interface Design GmbH; Managing Directors: Dr. Claus Goerner, Franz Koller; Head office: Ludwigsburg; Commercial register of the local court of Stuttgart, Germany, HRB 205519 +++ UID auf der CeBit 2008: Erleben Sie User Experience Management! Stand A20 UX08 in Halle 9. http://www.uid.com/cebit2008 +++ inline: no-top-post.png
Re: Please don't top post - (Re: Decouple fo from skinconf (was Re: svn commit: r618400 ))
I guess Ross was referring to me. Had to look up top post to know that he was referring to excessive quoting. And yes, I did. Was in a hurry and didn't clean up. Sorry! Add it to the sentence for merging my branch and temporarily breaking trunk assuming lazy consensus. Asche auf mein Haupt (what ever that is in English), Ferdinand Johannes Schaefer wrote: and whom ... me?! might be Ferdinand, see below
Re: Please don't top post - (Re: Decouple fo from skinconf (was Re: svn commit: r618400 ))
On Mon, 2008-02-18 at 16:50 +0100, Ferdinand Soethe wrote: I guess Ross was referring to me. Had to look up top post to know that he was referring to excessive quoting. Hmm, you both doing it. ;) Top post means (as I understand it) to add your answer to the top and the rest of the mails follows as it. The last post of you both had first thing your post, not as e.g. this answer where I answer in context. The problem is with top post is that if you give an answer one has to search the context (rest of the mail) to understand what is going on. salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
Re: Please don't top post - (Re: Decouple fo from skinconf (was Re: svn commit: r618400 ))
Thorsten Scherler schrieb: On Mon, 2008-02-18 at 16:50 +0100, Ferdinand Soethe wrote: I guess Ross was referring to me. Had to look up top post to know that he was referring to excessive quoting. Hmm, you both doing it. ;) Top post means (as I understand it) to add your answer to the top and the rest of the mails follows as it. The last post of you both had first thing your post, not as e.g. this answer where I answer in context. Sorry, I got it wrong. I thought Ross referred to e-mails out of the thread The problem is with top post is that if you give an answer one has to search the context (rest of the mail) to understand what is going on. I'll try to improve ;-) Johannes salu2 -- User Interface Design GmbH, Ludwigsburg (Germany) Phone/Fax +49 7141 37700-46/-99, Mobile +49 170 4914567 E-mail [EMAIL PROTECTED] * www.uidesign.de Offices: Martin-Luther-Straße 57-59, D-71636 Ludwigsburg Truderinger Strasse 330, D-81825 Muenchen Friedrichsring 46, D-68161 Mannheim Hansastraße 7-11, 44137 Dortmund Legal information according to EHUG: User Interface Design GmbH; Managing Directors: Dr. Claus Goerner, Franz Koller; Head office: Ludwigsburg; Commercial register of the local court of Stuttgart, Germany, HRB 205519 +++ UID auf der CeBit 2008: Erleben Sie User Experience Management! Stand A20 UX08 in Halle 9. http://www.uid.com/cebit2008 +++
Re: Decouple fo from skinconf (was Re: svn commit: r618400 )
On Mon, 2008-02-18 at 11:44 +, Ross Gardler wrote: Ferdinand Soethe wrote: The pdf-plugin will not work with 0.8 as is because it was decided to move critical libs from the plugin back into core. I must have missed that. Why were they moved back in? I think there was a misunderstanding. commons-io-1.3.1.jar - should go into the plugin (because other code does not seem to need it) commons-logging-1.1.1.jar - tricky since in 08 we have commons-logging-1.0.4.jar xmlgraphics-commons-1.2.jar - not in 0.8 but needed by the plugin (should go into the plugin) What was the problem with moving them into the plugin? http://marc.info/?l=forrest-devw=2r=1s=r618371q=b What I haven't tested so far is if 0.8 will work with a locally deployed plugin that is marked for 0.9? It won't (not tested, so I should say it shouldn't). IMO the plugin should work in 0.8 if the libs go back. We can release the plugin in version 0.3 (compatible with 0.8) and then raise the version to 0.4. salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
