forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: Decouple fo from skinconf (was Re: svn commit: r618400 )
Date Wed, 06 Feb 2008 20:51:27 GMT
On Wed, 2008-02-06 at 08:20 +0000, 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 
> > <pdf>
> >    ...
> >     <page size="letter" orientation="portrait" text-align="left"/>
> > 
> > into e.g. forrest.properties.xml:
> > <properties>
> >   <property name="pdf.page.size" value="letter"/>
> >   <property name="pdf.page.orientation" value="portrait"/>
> >   <property name="pdf.page.text-align" value="left"/>
> > ...
> 
> -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


Mime
View raw message