forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: maintain skinconf.xml etc. (Was: svn commit: r366100)
Date Fri, 06 Jan 2006 06:02:58 GMT
David Crossley wrote:
> Ross Gardler wrote:
> > Thorsten Scherler wrote:
> > 
> > >The solution David has chosen you still can define your minimum
> > >configuration even if you just override one property. Besides he added a
> > >nice header that you can add any given property again by looking up the
> > >fresh-site file (we everything is pretty much described).
> > 
> > You are mixing the two commits David made. One was to clear out 
> > unnecessary stuff from plugins etc. I'm +1 for that. The other is the 
> > one above, this is for the template sites. These are used by users as a 
> > starting point and therefore extra documentation in there will reduce 
> > the number of questions we get on the mailing lists.
> > 
> > >Another way is to define a svn:ext. Meaning all template sites would
> > >keep the blown away properties to play around but we as project have to
> > >maintain only one (e.g. the one from fresh-site).
> > 
> > +1 (for the seed sites only - I'm happy with the minimal stuff in 
> > plugins etc. that are not used by users in the same way)
> Okay, i will try to find another way to avoid the
> duplication.
> What i was trying to do was to make the "seed-sample" site
> the fully-documented one for all reference.
> I considered that the "basic" one should be basic,
> but Tim's httpd.conf analogy is good. I will put
> them back to "basic" and "business".


> I reckon that "benchmark" can be minimal. I also want
> to keep the "v3" minimal. The "v2" i have not touched
> because i presume that it will be entirely removed prior
> to the 0.8 release.


> To link the history of the discussion for the archives:
> As mentioned there, Reinhard did some experimentation
> at Cocoon-2.2 (pre Daisy docs) that used svn:externals
> to maintain the and skinconf.xml etc.
> I will investigate and report back. I get the feeling
> that it only operates at directory level.

Here is a summary of his technique. There are two aspects:
- including copy of common configuration files via svn:externals
- using xml entities to manage common sections of xml files

Standard configuration files are at
There are various things here such as sitemap.xmap
and stylesheets which we would not need for our situation.

Using 'svn:externals' this directory is created wherever it
is needed, e.g. under
So the tree is ...
 |-- src (this second src directory was a forrest config mistake)
     |-- content
     |-- forrest-configuration  <---------
     |-- skinconf.xml

The refers to resources in the
forrest-configuration directory.

The skinconf.xml declares some of its own stuff,
and includes other skinconf.xml files by using
xml entities. Clever.


So we could use this technique for managing the config
files of our plugins. At the moment the only ones
that i can think of is skinconf.xml and maybe the file. Later we might need
to include others.

What do you reckon?


> The other thing that we discussed (need to find the thread)
> was to streamline these "seed" sites so that we can
> generate various seed sites, e.g. one that strips
> out the Apache licensing info.

I reckon leave this until stage two.


View raw message