Re: Placement of common libs (was Re: Decouple fo from skinconf (was Re: svn commit: r618400 ))
On Thu, 2008-02-21 at 18:13 +0100, Ferdinand Soethe wrote: > Since Jeremias is about to release fop 0.95 with yet more > significant improvements, I amend my proposal as follows > > Ferdinand Soethe wrote: > > > OK, so I'll wait for Johannes to finish his tests, fix what needs to be > > fixed then > > > > - copy the missing libs into the plugin, publish it as 0.3 > > requiring Forrest 0.8 > > > > - tag this state > > > > - then remove the libs from the plugin > update fop to 0.95 > > and publish it as 0.4 dev > > requiring Forrest 0.9. > > P.S.: Jeremias said that this update only requires an update >of the lib itself. Wrapper and all the rest remain the >same. Perfect. Awesome work Jeremias, big compliment to you and the fop community. +1 for the proposal. Thanks Ferdiand for taking the lead on this. salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
Re: Placement of common libs (was Re: Decouple fo from skinconf (was Re: svn commit: r618400 ))
Since Jeremias is about to release fop 0.95 with yet more significant improvements, I amend my proposal as follows Ferdinand Soethe wrote: OK, so I'll wait for Johannes to finish his tests, fix what needs to be fixed then - copy the missing libs into the plugin, publish it as 0.3 requiring Forrest 0.8 - tag this state - then remove the libs from the plugin update fop to 0.95 and publish it as 0.4 dev requiring Forrest 0.9. P.S.: Jeremias said that this update only requires an update of the lib itself. Wrapper and all the rest remain the same. Best regards, Ferdinand Soethe
Re: Placement of common libs (was Re: Decouple fo from skinconf (was Re: svn commit: r618400 ))
Ferdinand Soethe wrote: David Crossley wrote: Ferdinand Soethe wrote: ... - the create a branch pdf_plugin_03 Why? We haven't created a branch for any other plugin. Don't branch until we really need to. This was just to have the option of updating and releasing the plugin easily. Why not do what I suggested. Tag the trunk and create a branch if we need it. Tagging the trunk is a good idea. We should add that to our plugin development procedure howto doc. Does tagging mean that we mark the release where 0.3 changes to 0.4 and would be able to branch from there easily one there are updates to the stylesheets? Yes, although if we want to be pedantic we are tagging the state 0.3 plugin was in when it was released. SVN is a time machine. At any point you can go back in time and create a branch from that moment. You do this with revision numbers. Tagging is just a convenient was of marking important revisions. Ross
Re: Placement of common libs (was Re: Decouple fo from skinconf (was Re: svn commit: r618400 ))
David Crossley wrote: Ferdinand Soethe wrote: OK, so I'll wait for Johannes to finish his tests, fix what needs to be fixed then - copy the missing libs into the plugin, publish it as 0.3 requiring Forrest 0.8 And deploy/release it before moving on with code. yes, of course. - the create a branch pdf_plugin_03 Why? We haven't created a branch for any other plugin. Don't branch until we really need to. This was just to have the option of updating and releasing the plugin easily. It would be better to get moving with core 0.9 release. From my own experience I think that people will not always be able to follow us to a new release even if it was released soon. That's why I wanted to keep the option of updating the plugin for 0.8 Tagging the trunk is a good idea. We should add that to our plugin development procedure howto doc. Does tagging mean that we mark the release where 0.3 changes to 0.4 and would be able to branch from there easily one there are updates to the stylesheets? Best regards, Ferdinand Soethe
Re: Placement of common libs (was Re: Decouple fo from skinconf (was Re: svn commit: r618400 ))
Ferdinand Soethe wrote: > > OK, so I'll wait for Johannes to finish his tests, fix what > needs to be fixed then > > - copy the missing libs into the plugin, publish it as 0.3 > requiring Forrest 0.8 And deploy/release it before moving on with code. > - the create a branch pdf_plugin_03 Why? We haven't created a branch for any other plugin. Don't branch until we really need to. It would be better to get moving with core 0.9 release. Tagging the trunk is a good idea. We should add that to our plugin development procedure howto doc. -David > - then remove the libs from the plugin and publish it as 0.4 > requiring Forrest 0.9. > > Best regards, > Ferdinand Soethe
Re: Placement of common libs (was Re: Decouple fo from skinconf (was Re: svn commit: r618400 ))
On Tue, 2008-02-19 at 12:00 +0100, Ferdinand Soethe wrote: > OK, so I'll wait for Johannes to finish his tests, fix what > needs to be fixed then > > - copy the missing libs into the plugin, publish it as 0.3 >requiring Forrest 0.8 > > - the create a branch pdf_plugin_03 > > - then remove the libs from the plugin and publish it as 0.4 >requiring Forrest 0.9. +1 Thanks very much. salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
Re: Placement of common libs (was Re: Decouple fo from skinconf (was Re: svn commit: r618400 ))
OK, so I'll wait for Johannes to finish his tests, fix what needs to be fixed then - copy the missing libs into the plugin, publish it as 0.3 requiring Forrest 0.8 - the create a branch pdf_plugin_03 - then remove the libs from the plugin and publish it as 0.4 requiring Forrest 0.9. Best regards, Ferdinand Soethe
Re: Placement of common libs (was Re: Decouple fo from skinconf (was Re: svn commit: r618400 ))
Ferdinand Soethe wrote: Thorsten Scherler wrote: 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) No misunderstanding as far as I can tell. In the message http://marc.info/?l=forrest-dev&w=2&r=1&s=r618371&q=b you wrote That should not include common libs: [...] The following needs to be in core: Removed: forrest/branches/UpdateFOPto094/lib/core/commons-io-1.3.1.jar forrest/branches/UpdateFOPto094/lib/core/commons-logging-1.1.1.jar forrest/branches/UpdateFOPto094/lib/core/xmlgraphics-commons-1.2.jar and so I moved these libs back into core. And I think they should remain there now because _current common use_ is not really a useful criterion for placement of these libs. Somewhere along that road we'd start moving libs back into core when the next plugin requires them. Not if we get out act together and use IVY to retrieve libs. In this case not neither core nor plugins would require libs to be bundled. Your earlier approach makes a lot more sense to me. Place all libs that could be of a common use in lib/core right away. -0 I think that to have your FOP enhancements available in 0.8 without user intervention is important. If I had the time to do the IVY migration I'd be -1 on the above, but I'm not sure I have the time right now - hence only a -0 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. So I propose to _copy_ the missing libs into the plugin, publish it as 0.3 requiring Forrest 0.8, then remove the libs from the plugin and publish it as 0.4 requiring Forrest 0.9. +1 The only weak spot in proceeding like this is the difficulty of doing bugfixes (which are certainly to be expected) in the 0.3 version. Be sure to tag 0.3 and, if necessary, we can branch it for bug fixes. Ross: Is there really no way of maintaining two versions of a plugins sources in our svn? We'd really need it in this case! That's what branches are for. Ross
Placement of common libs (was Re: Decouple fo from skinconf (was Re: svn commit: r618400 ))
Thorsten Scherler wrote: 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) No misunderstanding as far as I can tell. In the message http://marc.info/?l=forrest-dev&w=2&r=1&s=r618371&q=b you wrote That should not include common libs: [...] The following needs to be in core: Removed: forrest/branches/UpdateFOPto094/lib/core/commons-io-1.3.1.jar forrest/branches/UpdateFOPto094/lib/core/commons-logging-1.1.1.jar forrest/branches/UpdateFOPto094/lib/core/xmlgraphics-commons-1.2.jar and so I moved these libs back into core. And I think they should remain there now because _current common use_ is not really a useful criterion for placement of these libs. Somewhere along that road we'd start moving libs back into core when the next plugin requires them. Your earlier approach makes a lot more sense to me. Place all libs that could be of a common use in lib/core right away. 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. So I propose to _copy_ the missing libs into the plugin, publish it as 0.3 requiring Forrest 0.8, then remove the libs from the plugin and publish it as 0.4 requiring Forrest 0.9. The only weak spot in proceeding like this is the difficulty of doing bugfixes (which are certainly to be expected) in the 0.3 version. Ross: Is there really no way of maintaining two versions of a plugins sources in our svn? We'd really need it in this case! Best regards, Ferdinand Soethe
Re: Decouple fo from skinconf (was Re: svn commit: r618400 )
On 19.02.2008 00:10:17 Thorsten Scherler wrote: > commons-logging-1.1.1.jar -> tricky since in 08 we have > commons-logging-1.0.4.jar FOP should work with 1.1.1 as we're not doing anything fancy in our sources. Jeremias Maerki
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-dev&w=2&r=1&s=r618371&q=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
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: 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 ))
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 ))
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 +++ <>
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
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 )
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 ? 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 ? 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 )
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 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 )
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: 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: Decouple fo from skinconf (was Re: svn commit: r618400 )
Thorsten Scherler wrote: On Wed, 2008-02-06 at 08:20 +, Ross Gardler wrote: Thorsten Scherler wrote: On Tue, 2008-02-05 at 03:49 +0100, Ferdinand Soethe wrote: If I understand you correctly I would have to add that pipeline to the plugins sitemap so that it looks for skinconf settings elsewhere and than what? Not exactly, it was more an example for the generator. Where and how would I have to store the settings formerly in skinconf? In forrest.properties or forrest.properties.xml. That would mean to flatten some ... into e.g. forrest.properties.xml: ... -1 This change makes any project using 0.3 PDF plugin incompatible with 0.2 (if the user has changed any of the skinconf properties). The user would need to update/migrate/implement this changes to the properties file (and only this changes since we are using fallbacks in properties). I reckon we are talking about a couple of this changes but I reckon in most case even less. It is an inconvenience to the user which brings no benefit other than behind the scenes. The question is therefore do we want tc inconvenience users without documented warnings? It also makes it really confusing as to where properties are stored in 0.9 As far as I remember we only use skinconf for core plugins. 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. Further we decided to introduce the properties system after 0.8 as configuration system AFAIR, meaning there is no confusion regarding in where to store properties. Yes, that's my point. Your proposal introduces the properties to a plugin for Forrest 0.8 which does *not* use the new system. To make this change in a core plugin I think we need to lose skinconf altogether and this will delay the release of the 0.3 PDF plugin considerably. Didn't we decided that plugins have an independent release cycle from core, or am I confusing this with cocoon 2.2 blocks? We did agree that. But, see my comment above this is a feature of Forrest 0.9 and you want to use it in a 0.8 plugin. Further I do not see the need that we need to loose skinconf altogether BEFORE the plugin can be released (I totally agree that we need to drop skinconf). I withdraw that assertion. My -1 stands for the reasons above. We should deprecate skinconf in PDF 0.3 and remove it in 0.4. Ross
Re: Decouple fo from skinconf (was Re: svn commit: r618400 )
On Wed, 2008-02-06 at 08:20 +, Ross Gardler wrote: > Thorsten Scherler wrote: > > On Tue, 2008-02-05 at 03:49 +0100, Ferdinand Soethe wrote: > >> If I understand you correctly I would have to add that > >> pipeline to the plugins sitemap so that it looks for > >> skinconf settings elsewhere and than what? > > > > Not exactly, it was more an example for the generator. > > > >> Where and how would I have to store the settings formerly in > >> skinconf? > > > > In forrest.properties or forrest.properties.xml. That would mean to > > flatten some > > > >... > > > > > > into e.g. forrest.properties.xml: > > > > > > > > > > ... > > -1 > > This change makes any project using 0.3 PDF plugin incompatible with 0.2 > (if the user has changed any of the skinconf properties). The user would need to update/migrate/implement this changes to the properties file (and only this changes since we are using fallbacks in properties). I reckon we are talking about a couple of this changes but I reckon in most case even less. > > It also makes it really confusing as to where properties are stored in > 0.9 As far as I remember we only use skinconf for core plugins. > Why are we using skinconf for core plugins? The only plugin that should use skinconf is a skin plugin (if it would exist)! Further we decided to introduce the properties system after 0.8 as configuration system AFAIR, meaning there is no confusion regarding in where to store properties. > To make this change in a core plugin I think we need to lose skinconf > altogether and this will delay the release of the 0.3 PDF plugin > considerably. Didn't we decided that plugins have an independent release cycle from core, or am I confusing this with cocoon 2.2 blocks? Further I do not see the need that we need to loose skinconf altogether BEFORE the plugin can be released (I totally agree that we need to drop skinconf). salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
Re: Decouple fo from skinconf (was Re: svn commit: r618400 )
Thorsten Scherler wrote: On Tue, 2008-02-05 at 03:49 +0100, Ferdinand Soethe wrote: If I understand you correctly I would have to add that pipeline to the plugins sitemap so that it looks for skinconf settings elsewhere and than what? Not exactly, it was more an example for the generator. Where and how would I have to store the settings formerly in skinconf? In forrest.properties or forrest.properties.xml. That would mean to flatten some ... into e.g. forrest.properties.xml: ... -1 This change makes any project using 0.3 PDF plugin incompatible with 0.2 (if the user has changed any of the skinconf properties). It also makes it really confusing as to where properties are stored in 0.9 As far as I remember we only use skinconf for core plugins. To make this change in a core plugin I think we need to lose skinconf altogether and this will delay the release of the 0.3 PDF plugin considerably. +1 for putting it in and deprecating the old method though. Ross
Re: Decouple fo from skinconf (was Re: svn commit: r618400 )
On Tue, 2008-02-05 at 03:49 +0100, Ferdinand Soethe wrote: > If I understand you correctly I would have to add that > pipeline to the plugins sitemap so that it looks for > skinconf settings elsewhere and than what? Not exactly, it was more an example for the generator. > > Where and how would I have to store the settings formerly in > skinconf? In forrest.properties or forrest.properties.xml. That would mean to flatten some ... into e.g. forrest.properties.xml: ... salu2 > > Best regards, > Ferdinand Soethe -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
Re: Decouple fo from skinconf (was Re: svn commit: r618400 )
If I understand you correctly I would have to add that pipeline to the plugins sitemap so that it looks for skinconf settings elsewhere and than what? Where and how would I have to store the settings formerly in skinconf? Best regards, Ferdinand Soethe
